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

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

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

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

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

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

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

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

這套設(shè)計經(jīng)驗只適用于所謂的面向接口的面向?qū)ο缶幊?，在純粹的面向?qū)ο缶幊讨?，也即對象之間只是通過互發(fā)消息來通信，根本就不必理會什么設(shè)計模式。我正在仿造WINDOWS的窗口框架，編寫一個面向?qū)ο蟮目蚣?，里面沒有繼承，沒有接口，沒有虛函數(shù)，對象之間只能通過消息進行交互。其實在動態(tài)語言和函數(shù)式語言，根本就沒有設(shè)計模式的用武之地@春秋十二月

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

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

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

@鐘謝偉
確實，如果沒有那么多要求，庫能提高開發(fā)效率，就算是再差的框架類庫，好比MFC，也都能夠起到很大的作用。只是，用糟糕的類庫，做出來的，也都是糟糕的產(chǎn)品。我們在使用一個類庫，類庫也同時在要求我們的設(shè)計，必須符合它的使用條件。

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

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

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

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

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

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

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

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

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

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

@zpkiller
在趕項目，下期是24點的程序，寫了一半，等項目完成后再補充

@flyinghearts
請確認，prev_permutation和next_permutation只能做全排列

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

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

@cexer
謝謝，這是一個系列，打算用C++清晰地表達一些玩具程序，干點實事，而不是整天用C++玩弄一些華而不實的語言技巧

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

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

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

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

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

爭取讓你一直圍觀下去@千暮（zblc）

細節(jié)確實是魔鬼，用C++開發(fā)，一定要花部分精力來專門對付細節(jié)，以方便其他地方，盡量避免接觸細節(jié)@pangzi

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

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

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

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

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

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