re: 類設計一則，GDI對象選入器 華夏之火 2012-06-01 23:05
確實創(chuàng)建GDI對象，是有點不明智，但使用起來，確實很方便，它是創(chuàng)建了GDI對象之后，就選入DC中，最后析構函數(shù)中或者再選入新的對象，會被選出來，然后給予刪除。至于那個reset，你說的也有道理，但是原本的職責中，本來就不想給用戶提供reset的機會@春秋十二月
re: 神奇的C數(shù)組 華夏之火 2012-06-01 22:58
我那樣寫只是比喻而已，實際編程中，我們很少需要寫排序的代碼@泡菜
re: 神奇的C數(shù)組 華夏之火 2012-06-01 22:35
我是C++迷，只是漸漸覺得之前忽略了太多c簡單的威力，卻沉迷于C++的復雜。另外，c數(shù)組由語言層直接支持，使用頻率也遠大于鏈表等東西。并且鏈表這些東西的一部分，自然也都看成鏈表等，但那只是概念上的看法，實際編程中誰會拿鏈表的一部分進行這樣使用的。@空明流轉
re: 類設計一則，GDI對象選入器 華夏之火 2012-06-01 18:42
不希望代碼只限于MFC中。關于reset的方法，之前也考慮過，但覺得沒有太多的必要，現(xiàn)在類中多增加一個可有可無的方法，都覺得很難受。@春秋十二月
re: 神奇的C數(shù)組 華夏之火 2012-06-01 18:24
確實，C語言的數(shù)組就是內(nèi)存連續(xù)的東西，內(nèi)存連續(xù)就可以看成是數(shù)組@春秋十二月
re: 試論C++類庫開發(fā)之難 華夏之火 2012-06-01 00:15
以后有機會的，我會將一些不涉及版權問題的代碼發(fā)上去。之前一時技癢，也在博客上寫了一點玩具代碼，唉，那些代碼，現(xiàn)在看來，自己都覺得難受@春秋十二月
re: MFC 多線程及線程同步 華夏之火 2012-06-01 00:01
難得，現(xiàn)在還有人如此細心地整理MFC的東西，贊一個
re: 試論C++類庫開發(fā)之難 華夏之火 2012-05-31 23:57
兄臺的面向對象思想還是停留在這個幾大原則的初級階段。在下現(xiàn)在寫代碼，才不管什么原則，大多數(shù)類都能嚴格地保持自身的獨立，然后再用頂層代碼將這些類組織起來@春秋十二月
re: WINDOWS與設計模式 華夏之火 2012-05-31 23:49
這套設計經(jīng)驗只適用于所謂的面向接口的面向對象編程，在純粹的面向對象編程中，也即對象之間只是通過互發(fā)消息來通信，根本就不必理會什么設計模式。我正在仿造WINDOWS的窗口框架，編寫一個面向對象的框架，里面沒有繼承，沒有接口，沒有虛函數(shù)，對象之間只能通過消息進行交互。其實在動態(tài)語言和函數(shù)式語言，根本就沒有設計模式的用武之地@春秋十二月
re: 試論C++類庫開發(fā)之難 華夏之火 2012-05-31 14:35
@春秋十二月
現(xiàn)在寫C++代碼，非常小心謹慎的使用里面的特性。就算是定義一個新的類，也要權衡再三，并且盡量保持這個類的成員函數(shù)的數(shù)量要盡可能的少
re: 試論C++類庫開發(fā)之難 華夏之火 2012-05-31 14:30
慚愧，你提到的那些，確實有好幾個沒仔細用過。我考察了一些知名類庫之后，基本上都是那個模樣，抽象過多，使用又甚是不便，這些類庫原本可以采用更加簡單的設計方案，真正能讓我稍微心服也只有STL，不免得出了以偏概全的結論。而反觀C的庫，總是那么簡潔，直接反映了其所要解決的問題的核心，至于JAVA、C#等語言，因為語言本身已經(jīng)統(tǒng)一了很多細節(jié)問題，它們的類庫用起來反而省事多了，就算它們要寫通用性的類，起碼也不用像C++那么多數(shù)量，而且就算要寫，也無須考慮太多細節(jié)問題，都是直接問題領域的@YzL
re: 試論C++類庫開發(fā)之難 華夏之火 2012-05-31 11:33
@guilin
BOOST這種將大部分精力用在語法糖上的玩意，不提也罷。當然，BOOST里面也有好幾個能做實事的好東西。至于GOOGLE的開源庫，確實不錯，只是數(shù)量也太少了，遠遠沒法滿足日常開發(fā)的需要
re: 試論C++類庫開發(fā)之難 華夏之火 2012-05-31 01:52
@鐘謝偉
確實，如果沒有那么多要求，庫能提高開發(fā)效率，就算是再差的框架類庫，好比MFC，也都能夠起到很大的作用。只是，用糟糕的類庫，做出來的，也都是糟糕的產(chǎn)品。我們在使用一個類庫，類庫也同時在要求我們的設計，必須符合它的使用條件。
re: MFC，一開始就錯了 華夏之火 2012-05-31 01:47
有道理。我們?yōu)槭裁匆獙FC如此責備求全，實在是因為如果不精通MFC，就沒辦法做出似模似樣的東西，但當你一次又一次深入地學習MFC的源碼之后，就會對它很失望。一個框架，如果要求用戶必須精通它，才能用得好，那真的是很失敗@遠行
re: MFC，一開始就錯了 華夏之火 2012-05-31 01:42
閣下很明智。嘿，你們的老師，那真是，不過大學里的老師，基本上都是這樣@墨魂
re: MFC，一開始就錯了 華夏之火 2012-05-31 01:39
要我說MFC的好話，還真不容易呢。但好話，基本上四大天王已經(jīng)說盡了，你要是感興趣，可以看看@鐘謝偉
re: MFC，一開始就錯了 華夏之火 2012-05-30 16:52
@地里的
很無奈，還在用MFC，公司要求，益發(fā)令人難受
re: MFC，一開始就錯了 華夏之火 2012-05-30 16:29
羨慕，沒有用過MFC，沒有經(jīng)歷過C++的細節(jié)糾纏折磨，幸福啊@路人甲
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
@空明流轉
自省和動態(tài)機制確實是界面框架的利器，但是，用C設計界面，簡簡單單，卻似乎從來都不存在這些問題。功能更豐富更強悍的C++， 起碼也要實現(xiàn)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++吧，不要匈牙利了，確實很難看，不要帶壞初學者
支持樓主，寧愿將文章寫得直白淺顯，節(jié)省讀者吸收消化的時間
re: C++雜談 華夏之火 2011-07-13 16:13
@陳良喬——《我的第一本C++書》
你的書通俗易懂，非常好，不僅僅合格而已，要是當初學編程時能看到這樣的書就好了。我的第一本程序書居然是小強的C語言，唉，悲劇……
re: C++雜談 華夏之火 2011-07-13 09:28
再次聲明，本人并沒有拍死BOOST，至于看不起C++0X，那更屬子虛烏有（此罪名是否Tuple、share_ptr在TR12中）。每一個類寫得再不好，都有其應用的場合，更何況BOOST中的東西。高并發(fā)網(wǎng)絡服務器，用share_ptr管理SESSION，確實不錯，但有多少人需要寫高并發(fā)網(wǎng)絡服務器的，此種高端的東西，更要有高水平的人來做，相信除了share_ptr，還有更好的方案，比如SESSION POOL。至于tuple，依然無法解決重新編譯的問題，返回tuple的時候，如果tuple中的類型改變了，所有使用到返回tuple的函數(shù)，還不是要重新編譯。@kevin
re: C++雜談 華夏之火 2011-07-12 17:44
這樣指責，有點冤枉auto_ptr了，auto_ptr旨在管理單個的對象，數(shù)組是其他智能指針的事情，至于多CPU環(huán)境，那對auto_ptr的要求也太高了，很多優(yōu)秀的class都無法勝任。在下沒有說boost不優(yōu)秀。C++教材其實也很難編的，小強就不要說了，提都不值得提@Chipset
re: C++雜談 華夏之火 2011-07-12 09:09
細節(jié)確實是魔鬼，用C++開發(fā)，一定要花部分精力來專門對付細節(jié)，以方便其他地方，盡量避免接觸細節(jié)@pangzi
re: C++雜談 華夏之火 2011-07-12 09:07
只考慮執(zhí)行性能和寫代碼可以偷懶，這種態(tài)度對C++不公平，也會導致一些項目的問題，C++有屬于自己的一套哲學角度@放屁阿狗
re: C++雜談 華夏之火 2011-07-12 09:03
很有道理，完全贊同。語言自然沒有錯，用匯編都可以寫出很優(yōu)秀的軟件，更何況是用C，只不過用C來開發(fā)，不僅僅只是設計數(shù)據(jù)結構和算法，還有更多問題要考慮，C勝在其簡單，敗也在其簡單，當然對于高手來說，這些都不是問題。C++自然很復雜，我相信任何一個人都可以掌握復雜的東西，但問題在于要用復雜的工具來簡化復雜的問題，而不是使原本就很復雜的問題變得更加復雜，至于OO等設計，不提也罷@楊粼波
re: C++雜談 華夏之火 2011-07-12 08:51
在下并不畏懼用C來開發(fā)，C的細節(jié)并不多，大部分語句，本人已有其對應的匯編代碼的條件反射。在下對BOOST也沒有嗤之以鼻。實在不明白閣下怎么對在下的誤解會如此之大@kevin
@虛心學習
不勞你建議了，只知道算法的人，其實很可憐。后面我會介紹獵人過河、24點算法等經(jīng)典問題，逐步引入動態(tài)規(guī)劃、回溯、定界分支等算法，旨在希望用C++清晰地表達想法。搭理你這類人，很有失身份，唉！
re: C++雜談 華夏之火 2011-07-11 12:00
大多數(shù)的內(nèi)存泄漏，都是設計上的缺陷@fx
re: C++雜談 華夏之火 2011-07-11 10:52
@Skill
只怕閣下更不懂得Boost和auto_ptr，而且也未必明白在下的文章要說什么，只想說在下最不依賴auto_ptr了