huaxiazhihuo

確實(shí)創(chuàng)建GDI對(duì)象，是有點(diǎn)不明智，但使用起來(lái)，確實(shí)很方便，它是創(chuàng)建了GDI對(duì)象之后，就選入DC中，最后析構(gòu)函數(shù)中或者再選入新的對(duì)象，會(huì)被選出來(lái)，然后給予刪除。至于那個(gè)reset，你說(shuō)的也有道理，但是原本的職責(zé)中，本來(lái)就不想給用戶提供reset的機(jī)會(huì)@春秋十二月

我那樣寫(xiě)只是比喻而已，實(shí)際編程中，我們很少需要寫(xiě)排序的代碼@泡菜

我是C++迷，只是漸漸覺(jué)得之前忽略了太多c簡(jiǎn)單的威力，卻沉迷于C++的復(fù)雜。另外，c數(shù)組由語(yǔ)言層直接支持，使用頻率也遠(yuǎn)大于鏈表等東西。并且鏈表這些東西的一部分，自然也都看成鏈表等，但那只是概念上的看法，實(shí)際編程中誰(shuí)會(huì)拿鏈表的一部分進(jìn)行這樣使用的。@空明流轉(zhuǎn)

不希望代碼只限于MFC中。關(guān)于reset的方法，之前也考慮過(guò)，但覺(jué)得沒(méi)有太多的必要，現(xiàn)在類(lèi)中多增加一個(gè)可有可無(wú)的方法，都覺(jué)得很難受。@春秋十二月

確實(shí)，C語(yǔ)言的數(shù)組就是內(nèi)存連續(xù)的東西，內(nèi)存連續(xù)就可以看成是數(shù)組@春秋十二月

以后有機(jī)會(huì)的，我會(huì)將一些不涉及版權(quán)問(wèn)題的代碼發(fā)上去。之前一時(shí)技癢，也在博客上寫(xiě)了一點(diǎn)玩具代碼，唉，那些代碼，現(xiàn)在看來(lái)，自己都覺(jué)得難受@春秋十二月

難得，現(xiàn)在還有人如此細(xì)心地整理MFC的東西，贊一個(gè)

兄臺(tái)的面向?qū)ο笏枷脒€是停留在這個(gè)幾大原則的初級(jí)階段。在下現(xiàn)在寫(xiě)代碼，才不管什么原則，大多數(shù)類(lèi)都能?chē)?yán)格地保持自身的獨(dú)立，然后再用頂層代碼將這些類(lèi)組織起來(lái)@春秋十二月

這套設(shè)計(jì)經(jīng)驗(yàn)只適用于所謂的面向接口的面向?qū)ο缶幊蹋诩兇獾拿嫦驅(qū)ο缶幊讨校布磳?duì)象之間只是通過(guò)互發(fā)消息來(lái)通信，根本就不必理會(huì)什么設(shè)計(jì)模式。我正在仿造WINDOWS的窗口框架，編寫(xiě)一個(gè)面向?qū)ο蟮目蚣埽锩鏇](méi)有繼承，沒(méi)有接口，沒(méi)有虛函數(shù)，對(duì)象之間只能通過(guò)消息進(jìn)行交互。其實(shí)在動(dòng)態(tài)語(yǔ)言和函數(shù)式語(yǔ)言，根本就沒(méi)有設(shè)計(jì)模式的用武之地@春秋十二月

@春秋十二月
現(xiàn)在寫(xiě)C++代碼，非常小心謹(jǐn)慎的使用里面的特性。就算是定義一個(gè)新的類(lèi)，也要權(quán)衡再三，并且盡量保持這個(gè)類(lèi)的成員函數(shù)的數(shù)量要盡可能的少

慚愧，你提到的那些，確實(shí)有好幾個(gè)沒(méi)仔細(xì)用過(guò)。我考察了一些知名類(lèi)庫(kù)之后，基本上都是那個(gè)模樣，抽象過(guò)多，使用又甚是不便，這些類(lèi)庫(kù)原本可以采用更加簡(jiǎn)單的設(shè)計(jì)方案，真正能讓我稍微心服也只有STL，不免得出了以偏概全的結(jié)論。而反觀C的庫(kù)，總是那么簡(jiǎn)潔，直接反映了其所要解決的問(wèn)題的核心，至于JAVA、C#等語(yǔ)言，因?yàn)檎Z(yǔ)言本身已經(jīng)統(tǒng)一了很多細(xì)節(jié)問(wèn)題，它們的類(lèi)庫(kù)用起來(lái)反而省事多了，就算它們要寫(xiě)通用性的類(lèi)，起碼也不用像C++那么多數(shù)量，而且就算要寫(xiě)，也無(wú)須考慮太多細(xì)節(jié)問(wèn)題，都是直接問(wèn)題領(lǐng)域的@YzL

@guilin
BOOST這種將大部分精力用在語(yǔ)法糖上的玩意，不提也罷。當(dāng)然，BOOST里面也有好幾個(gè)能做實(shí)事的好東西。至于GOOGLE的開(kāi)源庫(kù)，確實(shí)不錯(cuò)，只是數(shù)量也太少了，遠(yuǎn)遠(yuǎn)沒(méi)法滿足日常開(kāi)發(fā)的需要

@鐘謝偉
確實(shí)，如果沒(méi)有那么多要求，庫(kù)能提高開(kāi)發(fā)效率，就算是再差的框架類(lèi)庫(kù)，好比MFC，也都能夠起到很大的作用。只是，用糟糕的類(lèi)庫(kù)，做出來(lái)的，也都是糟糕的產(chǎn)品。我們?cè)谑褂靡粋€(gè)類(lèi)庫(kù)，類(lèi)庫(kù)也同時(shí)在要求我們的設(shè)計(jì)，必須符合它的使用條件。

有道理。我們?yōu)槭裁匆獙?duì)MFC如此責(zé)備求全，實(shí)在是因?yàn)槿绻痪∕FC，就沒(méi)辦法做出似模似樣的東西，但當(dāng)你一次又一次深入地學(xué)習(xí)MFC的源碼之后，就會(huì)對(duì)它很失望。一個(gè)框架，如果要求用戶必須精通它，才能用得好，那真的是很失敗@遠(yuǎn)行

閣下很明智。嘿，你們的老師，那真是，不過(guò)大學(xué)里的老師，基本上都是這樣@墨魂

要我說(shuō)MFC的好話，還真不容易呢。但好話，基本上四大天王已經(jīng)說(shuō)盡了，你要是感興趣，可以看看@鐘謝偉

@地里的
很無(wú)奈，還在用MFC，公司要求，益發(fā)令人難受

羨慕，沒(méi)有用過(guò)MFC，沒(méi)有經(jīng)歷過(guò)C++的細(xì)節(jié)糾纏折磨，幸福啊@路人甲

QT確實(shí)用著要比MFC爽，但我過(guò)去一直就喜歡MFC的復(fù)雜@2

QT自己搞了一套標(biāo)準(zhǔn)，還要先重新編譯過(guò)，不喜歡。并且動(dòng)輒十幾M的庫(kù)庫(kù)，更加不喜歡。@地里的

不好意思，說(shuō)錯(cuò)了，C的簡(jiǎn)單是指語(yǔ)言層面，于是，用它設(shè)計(jì)做出來(lái)的東西，非常實(shí)在，不會(huì)讓你疑神疑鬼。框架確實(shí)有局限，但MFC也管得太嚴(yán)了，除非對(duì)MFC太過(guò)精通，否則難以除破它的種種限制@空明流轉(zhuǎn)

WTL也不了多少，不過(guò)是效率上去了而已，靈活性還是沒(méi)有原始的C那么好@漂漂

@空明流轉(zhuǎn)
自省和動(dòng)態(tài)機(jī)制確實(shí)是界面框架的利器，但是，用C設(shè)計(jì)界面，簡(jiǎn)簡(jiǎn)單單，卻似乎從來(lái)都不存在這些問(wèn)題。功能更豐富更強(qiáng)悍的C++， 起碼也要實(shí)現(xiàn)C能做到的一切事情，并且，最后的效果，絕不能比C遜色。但可惜MFC，明顯做不到

@zpkiller
在趕項(xiàng)目，下期是24點(diǎn)的程序，寫(xiě)了一半，等項(xiàng)目完成后再補(bǔ)充

@flyinghearts
請(qǐng)確認(rèn)，prev_permutation和next_permutation只能做全排列

@chipset
next_permutation和prev_permutation只能應(yīng)對(duì)全排列，本文只是為部分排列和組合而準(zhǔn)備的

@cexer
高手啊！只是近來(lái)頗為反感BOOST中的種種精巧的玩意，搞得大部分人對(duì)C++望而生畏。其實(shí)不搞花招，完全可以用C++寫(xiě)出非常清晰的代碼。只要用上了花招，我就會(huì)懷疑那些代碼的設(shè)計(jì)是否有問(wèn)題，有必要那樣拐彎抹角嗎

@cexer
謝謝，這是一個(gè)系列，打算用C++清晰地表達(dá)一些玩具程序，干點(diǎn)實(shí)事，而不是整天用C++玩弄一些華而不實(shí)的語(yǔ)言技巧

萬(wàn)惡的匈牙利命名法，丑陋的匈牙利命名法， 有同感！樓主是在講解標(biāo)準(zhǔn)C++吧，不要匈牙利了，確實(shí)很難看，不要帶壞初學(xué)者

支持樓主，寧愿將文章寫(xiě)得直白淺顯，節(jié)省讀者吸收消化的時(shí)間

@陳良喬——《我的第一本C++書(shū)》
你的書(shū)通俗易懂，非常好，不僅僅合格而已，要是當(dāng)初學(xué)編程時(shí)能看到這樣的書(shū)就好了。我的第一本程序書(shū)居然是小強(qiáng)的C語(yǔ)言，唉，悲劇……

再次聲明，本人并沒(méi)有拍死BOOST，至于看不起C++0X，那更屬子虛烏有（此罪名是否Tuple、share_ptr在TR12中）。每一個(gè)類(lèi)寫(xiě)得再不好，都有其應(yīng)用的場(chǎng)合，更何況BOOST中的東西。高并發(fā)網(wǎng)絡(luò)服務(wù)器，用share_ptr管理SESSION，確實(shí)不錯(cuò)，但有多少人需要寫(xiě)高并發(fā)網(wǎng)絡(luò)服務(wù)器的，此種高端的東西，更要有高水平的人來(lái)做，相信除了share_ptr，還有更好的方案，比如SESSION POOL。至于tuple，依然無(wú)法解決重新編譯的問(wèn)題，返回tuple的時(shí)候，如果tuple中的類(lèi)型改變了，所有使用到返回tuple的函數(shù)，還不是要重新編譯。@kevin

這樣指責(zé)，有點(diǎn)冤枉auto_ptr了，auto_ptr旨在管理單個(gè)的對(duì)象，數(shù)組是其他智能指針的事情，至于多CPU環(huán)境，那對(duì)auto_ptr的要求也太高了，很多優(yōu)秀的class都無(wú)法勝任。在下沒(méi)有說(shuō)boost不優(yōu)秀。C++教材其實(shí)也很難編的，小強(qiáng)就不要說(shuō)了，提都不值得提@Chipset

爭(zhēng)取讓你一直圍觀下去@千暮（zblc）

細(xì)節(jié)確實(shí)是魔鬼，用C++開(kāi)發(fā)，一定要花部分精力來(lái)專(zhuān)門(mén)對(duì)付細(xì)節(jié)，以方便其他地方，盡量避免接觸細(xì)節(jié)@pangzi

只考慮執(zhí)行性能和寫(xiě)代碼可以偷懶，這種態(tài)度對(duì)C++不公平，也會(huì)導(dǎo)致一些項(xiàng)目的問(wèn)題，C++有屬于自己的一套哲學(xué)角度@放屁阿狗

很有道理，完全贊同。語(yǔ)言自然沒(méi)有錯(cuò)，用匯編都可以寫(xiě)出很優(yōu)秀的軟件，更何況是用C，只不過(guò)用C來(lái)開(kāi)發(fā)，不僅僅只是設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)和算法，還有更多問(wèn)題要考慮，C勝在其簡(jiǎn)單，敗也在其簡(jiǎn)單，當(dāng)然對(duì)于高手來(lái)說(shuō)，這些都不是問(wèn)題。C++自然很復(fù)雜，我相信任何一個(gè)人都可以掌握復(fù)雜的東西，但問(wèn)題在于要用復(fù)雜的工具來(lái)簡(jiǎn)化復(fù)雜的問(wèn)題，而不是使原本就很復(fù)雜的問(wèn)題變得更加復(fù)雜，至于OO等設(shè)計(jì)，不提也罷@楊粼波

在下并不畏懼用C來(lái)開(kāi)發(fā)，C的細(xì)節(jié)并不多，大部分語(yǔ)句，本人已有其對(duì)應(yīng)的匯編代碼的條件反射。在下對(duì)BOOST也沒(méi)有嗤之以鼻。實(shí)在不明白閣下怎么對(duì)在下的誤解會(huì)如此之大@kevin

@虛心學(xué)習(xí)
不勞你建議了，只知道算法的人，其實(shí)很可憐。后面我會(huì)介紹獵人過(guò)河、24點(diǎn)算法等經(jīng)典問(wèn)題，逐步引入動(dòng)態(tài)規(guī)劃、回溯、定界分支等算法，旨在希望用C++清晰地表達(dá)想法。搭理你這類(lèi)人，很有失身份，唉！

大多數(shù)的內(nèi)存泄漏，都是設(shè)計(jì)上的缺陷@fx

@Skill
只怕閣下更不懂得Boost和auto_ptr，而且也未必明白在下的文章要說(shuō)什么，只想說(shuō)在下最不依賴auto_ptr了