re: 类设计一则，GDI对象选入器 华夏之火 2012-06-01 23:05
确实创建GDI对象，是有点不明智，但使用起来，确实很方便，它是创建了GDI对象之后，就选入DC中，最后析构函数中或者再选入新的对象，会被选出来，然后给予删除。至于那个reset，你说的也有道理，但是原本的职责中，本来就不想给用户提供reset的机会@春秋十二月
re: 神奇的C数组 华夏之火 2012-06-01 22:58
我那样写只是比喻而已，实际编程中，我们很少需要写排序的代码@泡菜
re: 神奇的C数组 华夏之火 2012-06-01 22:35
我是C++迷，只是渐渐觉得之前忽略了太多c简单的威力，却沉迷于C++的复杂。另外，c数组由语言层直接支持，使用频率也远大于链表等东西。并且链表这些东西的一部分，自然也都看成链表等，但那只是概念上的看法，实际编程中谁会拿链表的一部分进行这样使用的。@空明流转
re: 类设计一则，GDI对象选入器 华夏之火 2012-06-01 18:42
不希望代码只限于MFC中。关于reset的方法，之前也考虑过，但觉得没有太多的必要，现在类中多增加一个可有可无的方法，都觉得很难受。@春秋十二月
re: 神奇的C数组 华夏之火 2012-06-01 18:24
确实，C语言的数组就是内存连续的东西，内存连续就可以看成是数组@春秋十二月
re: 试论C++类库开发之难 华夏之火 2012-06-01 00:15
以后有机会的，我会将一些不涉及版权问题的代码发上去。之前一时技痒，也在博客上写了一点玩具代码，唉，那些代码，现在看来，自己都觉得难受@春秋十二月
re: MFC 多线程及线程同步 华夏之火 2012-06-01 00:01
难得，现在还有人如此细心地整理MFC的东西，赞一个
re: 试论C++类库开发之难 华夏之火 2012-05-31 23:57
兄台的面向对象思想还是停留在这个几大原则的初级阶段。在下现在写代码，才不管什么原则，大多数类都能严格地保持自身的独立，然后再用顶层代码将这些类组织起来@春秋十二月
re: WINDOWS与设计模式 华夏之火 2012-05-31 23:49
这套设计经验只适用于所谓的面向接口的面向对象编程，在纯粹的面向对象编程中，也即对象之间只是通过互发消息来通信，根本就不必理会什么设计模式。我正在仿造WINDOWS的窗口框架，编写一个面向对象的框架，里面没有继承，没有接口，没有虚函数，对象之间只能通过消息进行交互。其实在动态语言和函数式语言，根本就没有设计模式的用武之地@春秋十二月
re: 试论C++类库开发之难 华夏之火 2012-05-31 14:35
@春秋十二月
现在写C++代码，非常小心谨慎的使用里面的特性。就算是定义一个新的类，也要权衡再三，并且尽量保持这个类的成员函数的数量要尽可能的少
re: 试论C++类库开发之难 华夏之火 2012-05-31 14:30
惭愧，你提到的那些，确实有好几个没仔细用过。我考察了一些知名类库之后，基本上都是那个模样，抽象过多，使用又甚是不便，这些类库原本可以采用更加简单的设计方案，真正能让我稍微心服也只有STL，不免得出了以偏概全的结论。而反观C的库，总是那么简洁，直接反映了其所要解决的问题的核心，至于JAVA、C#等语言，因为语言本身已经统一了很多细节问题，它们的类库用起来反而省事多了，就算它们要写通用性的类，起码也不用像C++那么多数量，而且就算要写，也无须考虑太多细节问题，都是直接问题领域的@YzL
re: 试论C++类库开发之难 华夏之火 2012-05-31 11:33
@guilin
BOOST这种将大部分精力用在语法糖上的玩意，不提也罢。当然，BOOST里面也有好几个能做实事的好东西。至于GOOGLE的开源库，确实不错，只是数量也太少了，远远没法满足日常开发的需要
re: 试论C++类库开发之难 华夏之火 2012-05-31 01:52
@钟谢伟
确实，如果没有那么多要求，库能提高开发效率，就算是再差的框架类库，好比MFC，也都能够起到很大的作用。只是，用糟糕的类库，做出来的，也都是糟糕的产品。我们在使用一个类库，类库也同时在要求我们的设计，必须符合它的使用条件。
re: MFC，一开始就错了 华夏之火 2012-05-31 01:47
有道理。我们为什么要对MFC如此责备求全，实在是因为如果不精通MFC，就没办法做出似模似样的东西，但当你一次又一次深入地学习MFC的源码之后，就会对它很失望。一个框架，如果要求用户必须精通它，才能用得好，那真的是很失败@远行
re: MFC，一开始就错了 华夏之火 2012-05-31 01:42
阁下很明智。嘿，你们的老师，那真是，不过大学里的老师，基本上都是这样@墨魂
re: MFC，一开始就错了 华夏之火 2012-05-31 01:39
要我说MFC的好话，还真不容易呢。但好话，基本上四大天王已经说尽了，你要是感兴趣，可以看看@钟谢伟
re: MFC，一开始就错了 华夏之火 2012-05-30 16:52
@地里的
很无奈，还在用MFC，公司要求，益发令人难受
re: MFC，一开始就错了 华夏之火 2012-05-30 16:29
羡慕，没有用过MFC，没有经历过C++的细节纠缠折磨，幸福啊@路人甲
re: MFC，一开始就错了 华夏之火 2012-05-30 16:28
QT确实用着要比MFC爽，但我过去一直就喜欢MFC的复杂@2
re: MFC，一开始就错了 华夏之火 2012-05-30 16:26
QT自己搞了一套标准，还要先重新编译过，不喜欢。并且动辄十几M的库库，更加不喜欢。@地里的
re: MFC，一开始就错了 华夏之火 2012-05-30 16:24
不好意思，说错了，C的简单是指语言层面，于是，用它设计做出来的东西，非常实在，不会让你疑神疑鬼。框架确实有局限，但MFC也管得太严了，除非对MFC太过精通，否则难以除破它的种种限制@空明流转
re: MFC，一开始就错了 华夏之火 2012-05-30 15:19
WTL也不了多少，不过是效率上去了而已，灵活性还是没有原始的C那么好@漂漂
re: MFC，一开始就错了 华夏之火 2012-05-30 15:18
@空明流转
自省和动态机制确实是界面框架的利器，但是，用C设计界面，简简单单，却似乎从来都不存在这些问题。功能更丰富更强悍的C++， 起码也要实现C能做到的一切事情，并且，最后的效果，绝不能比C逊色。但可惜MFC，明显做不到
re: C++代码（4）排列与组合 华夏之火 2011-08-04 17:59
@zpkiller
在赶项目，下期是24点的程序，写了一半，等项目完成后再补充
re: C++代码（4）排列与组合 华夏之火 2011-07-20 00:13
@flyinghearts
请确认，prev_permutation和next_permutation只能做全排列
re: C++代码（3）全排列 华夏之火 2011-07-16 12:02
@chipset
next_permutation和prev_permutation只能应对全排列，本文只是为部分排列和组合而准备的
re: C++杂谈 华夏之火 2011-07-15 08:49
@cexer
高手啊！只是近来颇为反感BOOST中的种种精巧的玩意，搞得大部分人对C++望而生畏。其实不搞花招，完全可以用C++写出非常清晰的代码。只要用上了花招，我就会怀疑那些代码的设计是否有问题，有必要那样拐弯抹角吗
re: C++代码（2）八皇后问题 华夏之火 2011-07-15 08:45
@cexer
谢谢，这是一个系列，打算用C++清晰地表达一些玩具程序，干点实事，而不是整天用C++玩弄一些华而不实的语言技巧
re: 打包复杂：结构体的定义 华夏之火 2011-07-14 11:37
万恶的匈牙利命名法，丑陋的匈牙利命名法， 有同感！楼主是在讲解标准C++吧，不要匈牙利了，确实很难看，不要带坏初学者
re: 排排坐，吃果果：数组的声明与初始化 华夏之火 2011-07-13 19:46
支持楼主，宁愿将文章写得直白浅显，节省读者吸收消化的时间
re: C++杂谈 华夏之火 2011-07-13 16:13
@陈良乔——《我的第一本C++书》
你的书通俗易懂，非常好，不仅仅合格而已，要是当初学编程时能看到这样的书就好了。我的第一本程序书居然是小强的C语言，唉，悲剧……
re: C++杂谈 华夏之火 2011-07-13 09:28
再次声明，本人并没有拍死BOOST，至于看不起C++0X，那更属子虚乌有（此罪名是否Tuple、share_ptr在TR12中）。每一个类写得再不好，都有其应用的场合，更何况BOOST中的东西。高并发网络服务器，用share_ptr管理SESSION，确实不错，但有多少人需要写高并发网络服务器的，此种高端的东西，更要有高水平的人来做，相信除了share_ptr，还有更好的方案，比如SESSION POOL。至于tuple，依然无法解决重新编译的问题，返回tuple的时候，如果tuple中的类型改变了，所有使用到返回tuple的函数，还不是要重新编译。@kevin
re: C++杂谈 华夏之火 2011-07-12 17:44
这样指责，有点冤枉auto_ptr了，auto_ptr旨在管理单个的对象，数组是其他智能指针的事情，至于多CPU环境，那对auto_ptr的要求也太高了，很多优秀的class都无法胜任。在下没有说boost不优秀。C++教材其实也很难编的，小强就不要说了，提都不值得提@Chipset
re: 质朴的C++代码（1）因数分解 华夏之火 2011-07-12 09:10
争取让你一直围观下去@千暮（zblc）
re: C++杂谈 华夏之火 2011-07-12 09:09
细节确实是魔鬼，用C++开发，一定要花部分精力来专门对付细节，以方便其他地方，尽量避免接触细节@pangzi
re: C++杂谈 华夏之火 2011-07-12 09:07
只考虑执行性能和写代码可以偷懒，这种态度对C++不公平，也会导致一些项目的问题，C++有属于自己的一套哲学角度@放屁阿狗
re: C++杂谈 华夏之火 2011-07-12 09:03
很有道理，完全赞同。语言自然没有错，用汇编都可以写出很优秀的软件，更何况是用C，只不过用C来开发，不仅仅只是设计数据结构和算法，还有更多问题要考虑，C胜在其简单，败也在其简单，当然对于高手来说，这些都不是问题。C++自然很复杂，我相信任何一个人都可以掌握复杂的东西，但问题在于要用复杂的工具来简化复杂的问题，而不是使原本就很复杂的问题变得更加复杂，至于OO等设计，不提也罢@杨粼波
re: C++杂谈 华夏之火 2011-07-12 08:51
在下并不畏惧用C来开发，C的细节并不多，大部分语句，本人已有其对应的汇编代码的条件反射。在下对BOOST也没有嗤之以鼻。实在不明白阁下怎么对在下的误解会如此之大@kevin
re: 质朴的C++代码（1）因数分解 华夏之火 2011-07-11 15:29
@虚心学习
不劳你建议了，只知道算法的人，其实很可怜。后面我会介绍猎人过河、24点算法等经典问题，逐步引入动态规划、回溯、定界分支等算法，旨在希望用C++清晰地表达想法。搭理你这类人，很有失身份，唉！
re: C++杂谈 华夏之火 2011-07-11 12:00
大多数的内存泄漏，都是设计上的缺陷@fx
re: C++杂谈 华夏之火 2011-07-11 10:52
@Skill
只怕阁下更不懂得Boost和auto_ptr，而且也未必明白在下的文章要说什么，只想说在下最不依赖auto_ptr了