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