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