re: 回顧C++ 華夏之火 2017-07-17 11:32
@天下
C形式的dll顯然不夠用。其實，只要在c的基礎上再做多一些工作，情況就會好很多，但是委員會向來追求大而全的陋習，比如要支持虛繼承、要支持各種函數調用規定，要照顧各個編譯器的自定義等等因素，因此導致就連最基本的統一的面向對象模型都遲遲未曾出現
re: 再議c++的面向對象能力之上 華夏之火 2017-07-12 13:45
@天下
不要天真，動態語言比c++好多了，c++內核就是一團混亂，只有獨特口味的猿猴才會癡迷破爛c++，對這些geek來說，這并不是什么光彩的事情
re: stl的缺陷抽象不足 華夏之火 2017-07-10 14:08
@天下
mfc，xtream，qt都是垃圾，都不值得花時間。c++的gui開發，除了qt，似乎也沒有更好的選擇
re: 非完美的stl 華夏之火 2017-07-09 09:57
@萬連文
系統api的標準化是客觀原因，但是stl在二進制層面上的復用之難，真是令人發指。知乎c++板塊上的人氣比cppblog要更熱鬧。
re: 非完美的stl 華夏之火 2017-07-09 09:54
@天下
從c++17的提案上看，標準會對于stl的保守改進和迷糊認識，個人是徹底失望了。所幸的是，c++在大節上的進化還是可取的
re: 迭代器的抽象 華夏之火 2016-05-25 11:21
@linda
迭代器不僅僅是好東西，而是必須物，不可或缺。沒有迭代器的抽象，要么就是延遲求值，要么代碼就會寫起來很痛苦
re: 挖坑，有空填坑 華夏之火 2016-05-11 19:12
@春秋十二月
和c++無關的事情。C#，java，python，javascript等，主要還是C#
re: 挖坑，有空填坑 華夏之火 2016-05-10 18:20
@Richard Wei
一直都想回來的，不過，可能也來不了，很多代碼要寫，并且還不是用C++開發。很久沒用C++了
re: 挖坑，有空填坑 華夏之火 2016-05-10 10:03
老朽也排斥宏啊，但是，c++又沒有反射，沒有模式匹配，沒有原生的tupple支持等等，在用這些好東西的時候，不用宏，就要寫大量的重復代碼。比如，f1函數返回值為tupple<int,string>。與其寫：auto tt = f1();auto num=get<1>(tt);auto text=get<2>(tt);就不如用宏自動生成這三行代碼，TUPPLE_VALUES(num,text,f1)
re: MFC，一開始就錯了 華夏之火 2016-05-10 09:55
@呵呵
以90年代的標準來看，mfc還是很不錯的。那個時候沒有template，沒有exception，業界對于面向對象的思考也沒那么深刻。以那時的標準c++，沒有編譯器擴展，mfc真是相當不錯
re: C語言復雜聲明的本質與局限 華夏之火 2013-07-02 09:39
@tangzhnju
C++的復雜是多方面的，但引入更多關鍵字，估計將更加復雜
re: C語言復雜聲明的本質與局限 華夏之火 2013-07-02 09:35
@Quon
不采用C專家編程的那一套辦法，自然是故意的。但實質上，兩者的本質都是一致的，你應該看得出來，因為你應該已經完整看完了 C專家編程
re: 鍵盤布局的改進之道 華夏之火 2013-06-29 16:25
@waiting4you
罵得好
re: 鍵盤布局的改進之道 華夏之火 2013-06-29 10:22
@jl
所有一直在做MFC的人都很悲哀，大悲劇。仔細學習Vczh大神的博客，不失為開闊眼界的捷徑。在下眼界的開闊，走的是另外一條很長很長的彎路
re: 非理性擁護C++ 華夏之火 2012-11-23 23:21
@其實俺不是壞人
c的副作用相對來說沒那么變態，只是細節太繁瑣了，缺乏有效的語言工具來組織細節
re: 非理性擁護C++ 華夏之火 2012-11-23 23:19
@ooseven
c++本身也太復雜太自由了，對于同一個問題，總有很多種不同解決方法，并且每一種都有其存在的理由
re: 略說成員函數指針及其模板的精簡實現 華夏之火 2012-11-22 09:27
@fzy
有必要支持那么多嗎，只要typedef TRET (TClass::*P_METHOD)( TPARAM... )這一個就行了，void 確實比較特別
re: 非理性擁護C++ 華夏之火 2012-11-21 22:19
@人貴有自知之明
都已經說是非理性了，閣下又何必當真
re: 非理性擁護C++ 華夏之火 2012-11-21 22:17
@marvin
C++的語言核心還是很好的，就是整個業界很奇怪，都不知大家都在干什么。感覺應該是語言內部沒有統一的表現，c只要內存二進制兼容就好了，而其他語言，基本上一開始就統一了平臺，沒有那么多鬼鬼怪怪
re: 非理性擁護C++ 華夏之火 2012-11-21 22:09
@123
謝謝，其實說得不好，很情緒化
re: 非理性擁護C++ 華夏之火 2012-11-21 22:08
@fzy
的確，一不小心，c++就會變得很亂，現在到處一片混亂
re: 略說成員函數指針及其模板的精簡實現 華夏之火 2012-11-16 17:55
@Richard Wei
直接用function，會有心理負擔，雖然沒有必要
re: 范型編程雜談 華夏之火 2012-11-16 17:52
在下比較喜歡使用C++中template的代碼自動生成技術，由此感覺C++已通過泛型進入一個新的階段。只可惜目前還曲高和寡
re: 輕量級共享對象的靈巧指針的實現 華夏之火 2012-10-31 23:45
@羅朝輝
本靈巧指針只為構造共享對象，自產自毀，從不考慮承接外界的原生指針。提供思路而已，至于具體語法形式的考究，在下也不大感興趣。
re: 輕量級共享對象的靈巧指針的實現 華夏之火 2012-10-31 13:40
@無
2、在下覺得shared_ptr背后做的事情太多了，超出了它的原本要求。3、侵入式的理解，應該是針對是否影響了類的代碼而言，與內存在哪應該無關，好比在下的這個實現，就是非侵入式。4、拷貝構造函數中確實筆誤了，可參考后文改進版，析構也有改進，只是沒寫出來。5、開玩笑而已，感覺應該沒問題的，在下暫時還看不出來，你幫忙分析分析
re: 基于堆棧上的字符串實現 華夏之火 2012-09-05 11:01
CStackString＜1＞......CStackString<N>會導致編譯器生成N個類，確實會生成這么多類，但是，這些類的函數都在基類中了，只有一分。C++中，最后的執行文件中，不存在類這個概念，只有類的函數，也即是函數。至于構造函數，則全部被內聯@zgpxgame
re: 難以割舍的二段構造 華夏之火 2012-07-09 17:11
NEW/DELETE的問題不大，主要是某些較耗資源的玩意，好比線程、文件、數據庫連接，直接在構造函數中啟動，會讓人很糾結，覺得隱藏太多細節@哥沒注冊
re: 試論C++類庫開發之難 華夏之火 2012-07-09 17:09
說得好，關鍵是這盤菜是否標準化，能否到處通吃。@哥沒注冊
re: 試論C++類庫開發之難 華夏之火 2012-06-18 09:21
@jrry7
也許C++本身就不容許一統天下的東西存在。它喜歡自由、多樣化的世界。就算沒有性能的要求，開發人員都有自己喜歡的風格口味，眾口難調
re: 難以割舍的二段構造 華夏之火 2012-06-18 08:59
受教了，可能是在下內心對于異常的排斥，所以總是要盡量避免這個東西@guilin
re: 難以割舍的二段構造 華夏之火 2012-06-15 17:13
好比一個服務器類，我們一般都是先定義一個對象變量，然后讓變量開始監聽端口并啟動監聽的線程，這也可以看成二段構造吧。難道你要定義服務器對象的時候，就讓它在構造函數里面直接就開始監聽并啟動線程嗎@guilin
re: 跨越Win8 Metro開發 華夏之火 2012-06-15 12:11
大家都在Windows和C++上練就一身過硬內功，不懼怕任何跨越
re: 難以割舍的二段構造 華夏之火 2012-06-15 11:42
在下也知道不應該這樣用，只是碰到這樣的需求，該怎么辦，難道要用指針嗎？@guilin
re: 難以割舍的二段構造 華夏之火 2012-06-14 20:41
？這些都是深度探索c++對象模型中的內容，每一個想在c++上有所作為的人必須先深度探索這本書。@春秋十二月
re: 難以割舍的二段構造 華夏之火 2012-06-14 17:45
是啊，在下也偏向于精簡構造函數。對于多事的構造函數的代碼，內心總是很排斥，本能的對于細節的感興趣，或者這也是C++者們的通病@Richard Wei
re: 軟命令接口的適用場合 華夏之火 2012-06-13 11:21
在這種軟命令下，只能給對象發送消息，對象可以采取種種方式響應消息，甚至可在對象外面響應消息，在外面截取消息，不讓消息流進到之前的消息處理中。這樣，就不會存在什么復雜類層次結構。這種方式，在下認為并不是“單一入口的Faced模式”，而是幾乎包含了所有接口的變種橋接模式
re: C++11新特性不完全測試 華夏之火 2012-06-13 00:27
夜盼日盼，盼C++11橫行天下，到時用c++來寫代碼就爽了，最起碼，函數式的編程，在c++中，不會顯得那么丑陋。要是c++11不丟棄concept，那么，我會考慮全信心投入template中。
re: 一個高效的內存池實現 華夏之火 2012-06-13 00:23
對于c++類中的這種通過operator new，來使用特制的內存池的接口方式，我咋覺得很難受。如果類的內存池可由用戶來指定，那就很好了。不過我思考了很久，一直都找不到好的方式，實現出來的效果，總是使用的接口太難看了。最后，我心一橫，需要內存分配的對象，全部都是POD類型的，沒有構造析構，這樣用戶想要指定什么內存池，就用什么內存池
嗯，這個，我也承認，努力進步吧。當然，在下也不奢望一個小時內就寫完的代碼，能顯示出多大的火候@春秋十二月
至于《C++沉思錄》，早在很久以前，就翻爛了。c++中的書，大概也只有老爺子的書還有點看頭。現在寫代碼，做設計，都盡量不用繼承，連接口，可免則免@Richard Wei
這種消息處理的方式，大概是仁者見仁，智者見智吧。這里的實現，讓你覺得很難看，那只是因為缺乏了消息框架的支持，并且也是在下代碼寫得很急，沒進行任何優化。但即使這樣，也能顯示出這種方式的好處，那就是這個類的任何變化，都僅僅是只需要再增加幾個新的消息而已，不會影響用戶的原有代碼，也不要求重新編譯。@Richard Wei
re: 基于堆棧上的字符串實現 華夏之火 2012-06-08 13:58
_alloca，在C++中，貌似并不是很推薦，據說會帶來一些什么問題@春秋十一月
re: 基于堆棧上的字符串實現 華夏之火 2012-06-08 13:46
基于棧的內存分配器？在下也想看到，能否推薦一下。至于代碼膨脹，在這里的實現中，自然不會存在，你應該知道WHY的@zgpxgame
re: 基于堆棧上的字符串實現 華夏之火 2012-06-08 09:52
代碼中，我又作了修改。至于形如std::allocator的那種定制，也有其不足，比如，vector，因為采用不同的std::allocator的容器，都屬于不同的類型的vector，并且vector之間還不兼容呢@春秋十二月
是的，這個設計很丑陋很限制。我已作了修改@Richard Wei
re: 模板技術與應用(2): 類型選擇 華夏之火 2012-06-06 14:14
第一次看到這些神碼時，很激動。這么長時間過去了，現實中還真不容易找到它們的應用場合
re: WINDOWS與設計模式 華夏之火 2012-06-05 11:46
或者，設計模式能幫助碼農寫出好一點的所謂的面向對象的代碼，但也可能將代碼搞得更加復雜難懂了@123
re: 試論C++類庫開發之難 華夏之火 2012-06-04 00:03
我也深受C++毒害，咱倆算是同病相憐@10年碼農
re: MFC，一開始就錯了 華夏之火 2012-06-02 02:08
可是，我要說的是，即使沒有異常、dynamic_cast、type_info、template，甚至連虛函數都沒有，都可以寫出比MFC更好的框架@壞
re: 神奇的C數組 華夏之火 2012-06-01 23:08
先生要是覺得在下那樣寫變味了，那就算變味吧，在下只是表達自己對c數組的一點理解，旨在拋磚引玉，這不，就引來了您老人家的兩塊大玉了@泡菜