天秤座的唐風(fēng)

另，正在做提案去error-code化，加exception的體系設(shè)計。
但是做嵌入式，大家都很敏感，所以還是要先把現(xiàn)在所用的平臺和編譯環(huán)境中，exception空間和時間開銷分析清楚給客戶。目前還在整，感覺時間開銷上完全沒有問題（特別是normal case中，異常時其實(shí)慢一點(diǎn)也無所謂了，因?yàn)樵O(shè)計中的異常真的是非常非常地異常！），但代碼膨脹還是有點(diǎn)點(diǎn)擔(dān)心（因?yàn)榇鎯臻g比較有限）。不知道 MS 是不是有這方面的數(shù)據(jù)？特別是WinCE500方面……

異常處理這段深有同感。

現(xiàn)在做的系統(tǒng)中流用了大量的C代碼，全部是error-check方式。

只能說，用error－check大部情況下只是“掩耳盜鈴”而已，Check一下函數(shù)出錯了就打個屏，完全沒有想過是否可能恢復(fù)，如何恢復(fù)，也沒有辦法想，error-code根本就傳不出去。

所以軟件“品質(zhì)”就成了“測出來的”，而不是設(shè)計出來的了，因?yàn)樵O(shè)計的時候根本就無法處理這么復(fù)雜的層次的函數(shù)調(diào)用帶來的錯誤碼，而且中間只要有人不傳遞就完蛋了。

信了樓主的體驗(yàn)，升級了工程（當(dāng)然，偶是下的“試用”）
智能提示很慢，和VC助手的功能相比差距還是很明顯啊

不過2012啟動還是很快的。
雖然如此，還是受不了沒有助手的生活。
果斷退回

@chaogu
郁悶的是地大被定義為三流~而你還來一個“我是三流學(xué)校的怎么樣”
我可沒有因?yàn)樽约菏堑卮蟮亩杏X得有什么好郁悶的。我還是很懷念地大的生活的，呵呵。

看了你的自我介紹，中國地質(zhì)大學(xué)的校友郁悶地飄過~~~

@Tanky Woo
用Windows Live Writer寫，再發(fā)布，有圖的文章尤其方便撒~！

@空明流轉(zhuǎn)
興趣是有，圖形知識幾乎為0.
好吧，我申請去給你們打打雜~！
看你們收不？

造3D圖形引擎吧！

不記得是在哪里看到的了，大意是：
一個優(yōu)秀程序員要掌握的知識無論使用哪些語言都是差不多的，不同的地方在于：使用C++的話，你必須把它們大部都學(xué)會了，你才能動手做一些有實(shí)際意義的東西，（否則你將面臨著一大堆的陷阱）。而Java/C#等，則可以把學(xué)習(xí)的“時間”平攤，在你沒有“完全”掌握這些知識之前，你已經(jīng)可以做一些實(shí)際的東西出來了（雖然這個時候還稱不上是“優(yōu)秀”的程序員）。
我覺得，C++所謂的復(fù)雜性，大約就是這樣。
PS：把Java/C#放在這里并不想引起爭論。但是我想，如果世界只有一門語言的話，大概沒有誰會“抱怨”它的復(fù)雜性。要說它復(fù)雜，那是比起其它語言的“感覺”。所以，不比較是不可能的……好糾結(jié)

很少見到博客正文用楷體的，呵，不過博主的排版還是很漂亮的。
文章也讓我受教了。謝謝！

哈哈，好，這個系列會很有價值的樓主！

確實(shí)題目不清楚。呵呵

我只是模仿個 AGG ，亦有同感了。
唉

唉，還是希望出現(xiàn)語言級別的“糖”，還是希望有 initializer-list ……

這篇書評寫得非常棒！！
不過我覺得《算法導(dǎo)論》中的偽碼還是挺漂亮的，呵呵。

可惜我只看完圖算法就停下來了，習(xí)題基本沒做，買櫝還珠了，主要是沒有你這樣的毅力。PF你~！

gay……呵呵，搞錯詞了不老大~！

多用用標(biāo)準(zhǔn)庫就更好了。

@OwnWaterloo
很精彩，呵呵。
關(guān)于allocator這段，我看得很仔細(xì)，因?yàn)椋赥opLanguage里，有一個主題是《{技術(shù)}{C++} 突然有一種想法：將文本文件讀入vector可以跨過push_­back()嗎》
http://groups.google.com/group/pongba/browse_thread/thread/ebb85b7e927c1af9/aebc1741ed60b2f5?hl=zh-CN&lnk=gst&q=%E7%AA%81%E7%84%B6%E6%9C%89%E4%B8%80%E7%A7%8D%E6%83%B3%E6%B3%95%EF%BC%9A%E5%B0%86%E6%96%87%E6%9C%AC%E6%96%87%E4%BB%B6%E8%AF%BB%E5%85%A5vector%E5%8F%AF%E4%BB%A5%E8%B7%A8%E8%BF%87push_back()%E5%90%97#
我在里面表達(dá)了與OwnWaterloo同樣的觀點(diǎn)，但我的認(rèn)證和說明膚淺多了。我剛剛還特別翻了下，發(fā)現(xiàn)當(dāng)時的“辯方對友”居然正是樓主，世界太小了（樓主也是牛人，哪都見得到滴說）。

在這個問題上，我與OwnWaterloo相同，并從他的回答中又學(xué)到不少東西。我喜歡這樣的“技術(shù)論戰(zhàn)”，因?yàn)樗偸悄茏屓诉M(jìn)步，呵呵。向樓主，和OwnWaterloo學(xué)習(xí)。

@giscn
給些例子或是一些鏈接不咧
我贊同本文的觀點(diǎn)，但同時很想知道“遠(yuǎn)離 auto_ptr” 的理由是否也能說明我。

謝謝了。

@abilitytao
余的《文化苦旅》和《山居筆記》都灰常好看，高中的時候曾經(jīng)很迷，哈哈。
現(xiàn)在覺得他更像娛樂圈的人了……

我記得我背過這段，呵呵。

《山居筆記》里的吧
俺也挺喜歡看，高中時候的事兒了……唉，一恍7、8年。

@Uniker
看樣子您像是只看了標(biāo)題沒看內(nèi)容……

1. 遺留代碼不可替代
2. 升級開發(fā)環(huán)境的預(yù)算和必要性
3. 有決策權(quán)開發(fā)人員的“技術(shù)慣性”
使得VC6到現(xiàn)在還這么有“生命”力。感覺就像IE6一樣，哈哈，有種種的不好，可偏還是有那么多用戶。

反正我是等VS2010出來就準(zhǔn)備XX的，嘿嘿。

哈哈，這個猛！！

哈哈，期待下篇 Bug 解析！！

@陳梓瀚(vczh)
陳版 .net ？
哈哈~~~~

“像貴國的等級考試這類的考察語言偏僻細(xì)節(jié)上”？
請問閣下哪國人？

路過……
:)

唉，明修棧道，暗渡陳倉。

@Vitacy.Tan
話又說回來，在你的做法中，并沒有直接在 function pointer 和 void* 之間進(jìn)行轉(zhuǎn)型，而是為 function pointer 創(chuàng)建（new）了一個對象，賦給 void*，這樣做我感覺是沒有問題的，這時候 void* 指向的仍然是一個“對象”，呵呵。
但這么做可能在“效率”上不如直接備份 function pointer 。畢竟，創(chuàng)建時候的 new 和調(diào)用時的轉(zhuǎn)型加最后的 delete，都比直接存 function pointer 負(fù)擔(dān)大。但這樣做獲得了代碼上的一致性，我倒是挺喜歡的，呵呵（如果確實(shí)沒有“我所不知道的問題的話”）。

@Vitacy.Tan
在網(wǎng)上找了一下相關(guān)的資料，發(fā)現(xiàn)這個問題其實(shí)已經(jīng)有了比較多的“討論”，還有專門論述的文章：
http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html

簡而言之，就是：
不能 void* 和 void(*f)() 合并成一個，原因是對于 C 標(biāo)準(zhǔn)而言，這兩個“東西”并不保證一致，函數(shù)指針的大小可能比 void* （也就是指向數(shù)據(jù)的指針大小要大），可能會包含更多的信息，如果在這之間進(jìn)行轉(zhuǎn)換的話，在某些平臺會產(chǎn)生未定義的行為（在 Windows 平臺下，這樣做是沒問題的，參考http://stackoverflow.com/questions/1867698/casting-a-void-pointer-data-to-a-function-pointer 中的回復(fù)）。因此，這么做是為了可移植性的考慮。

相關(guān)原文如下：
Why can’t we use void* for a Generic Function Pointer?
This is because a void* is a pointer to a generic “data” type. A void * is used to denote pointers to objects and in some systems, pointers to functions can be larger than pointers to objects. So, if you convert amongst them, you’ll lose information and hence, the situation would be undefined and implementation dependent. Most compilers won’t even warn you if you convert between them but some might error out, if you try to call such a void * to function pointer converted. But even they might fail to alert you, if you take care of typecasting the call perfectly (Enclose in parentheses before function call brackets). And then, one fine day, you’ll try to compile and run your program on one of the aforementioned systems, and then keep on wondering why your program segfaults.

Note: C++ does allow this “conditionally” which means that such a conversion is allowed but a compiler is not bound to implement this feature, which again makes its usage circumspect.

另外，我還是不太明白，function pointer 可能攜帶的其它信息是什么，呵呵，再查查嘍。

謝謝 Vitacy.Tan 的回復(fù)，讓我能更深入的了解這方面的知識。
嗯，有人能參與討論就是好啊，希望大家多指點(diǎn)。

唐

謝謝你的總結(jié)！！
真是太好了，正在找這樣的資料，呵呵

C++0x 中貌似可以。
確實(shí)是一種很合理也很有用的初始化方式。

記得以前也做過樣的的東東，貌似是自己第一個PC程序呢，哈哈。
用C從頭做起，能練練數(shù)據(jù)結(jié)構(gòu)（主要是鏈表）。用C++/Java/C#等容器類，那就沒什么搞頭了，呵呵

>code3 錯誤的原因?yàn)? vecFiles.erase(it_pos); 當(dāng)前的it_pos已經(jīng)被刪除
>了, 再下一次循環(huán)的時候 it_pos++, 訪問非法內(nèi)存..

>然后回過頭來看code1, vecFiles.erase(it_pos++); 在當(dāng)前的it_pos已經(jīng)被
>刪除的時候, it_pos已經(jīng)指向下一個位置了. 雖然這里邏輯上是錯誤的. 但是利
>用c語法的特性產(chǎn)生了一個正確的結(jié)果, 算是一個技巧. 不算是一門技術(shù).

我對這種的說法有不同看法：
it_pos無所謂刪除不刪除，it_pos 的行為就像指針一樣，指針本身不會被刪除，被刪除的是指針指向的內(nèi)容。我想樓主可能對迭代器失效的理解有偏差（建議在網(wǎng)上查一查相關(guān)的資料再看看）
我覺得，code1、2、3沒有什么本質(zhì)區(qū)別，都有可能產(chǎn)生迭代器失效的問題。
一個原則：對vector只要做了刪除或是增加動作，就要示迭代器已經(jīng)無效，必須重新從vector對象獲取新的迭代器的值，而不能用臨時變量、后綴自增等方法……
remove_if+erase的版本才是可讀性最好且沒什么問題的。

個人愚見，請博主笑納……

@陳梓瀚(vczh)
好吧，我只能說，是你自己在 cppblog 的鏈接中列出來的。哈哈哈哈 :P
閣下愛好很廣嘛，編譯原理狂人（別人這么叫你的） + 漫迷 ……

嗯嗯，凡有回復(fù)必回訪是我的原則，哈哈，也是想通這這種途徑了解對方，多交些朋友

@Wang Feng
確實(shí)如你所言。謝謝你的回復(fù)。

說實(shí)話，“并行計算”這種高級貨，我還真沒玩過，嘿嘿。

嗯嗯，真心求教：
這方面有沒有比較好的已經(jīng)成熟的做法（庫？）？能不能介紹一下？如果一個表達(dá)式比較復(fù)雜（比如有加減乘、有括號之類）有什么算法能正確地最優(yōu)地根據(jù)可以并行的“行程”數(shù)來分配計算子過程？各子過程的之間的“通信”是怎么做的呢？會像一般“多線程”中的鎖機(jī)制那樣嗎（當(dāng)然，我對鎖這東西的理解也限于“理論”范疇內(nèi)，呵呵）？

PS:
剛才回訪了你的 blog，里面大多都是算法方面的東西啊，呵呵。向你學(xué)習(xí) :D

@YESHG!
你也注冊一個博客園（或是cppblog）的帳戶唄
對評論和回復(fù)有郵件通知，這個功能挺好用的。

【他只是謙虛地說：他只是對C++比較了解，在其他領(lǐng)域，他可能還不如在座諸位。】
光這一點(diǎn)就讓我肅然起敬。

@OwnWaterloo

operation proxy……

好形象啊，哈哈
你上篇的回復(fù)里就說到了這個呢，不過我是事后才認(rèn)識到……:P

@YESHG!
謝謝老大支持！！

配合內(nèi)聯(lián) RVO，很多情況下這些臨時小對象也可以消失，你看看我上面回復(fù)中給的鏈接，MS 有說明……

至于不習(xí)慣模板，嘿嘿，吐啊吐啊就習(xí)慣了。:)

@陳梓瀚(vczh)
嗯嗯，好敏銳啊，你說得很對。
d=a+(b+c);
這種在這段程序里是會產(chǎn)生編譯錯誤的……

這個模板類確實(shí)非常的不完善，對于一個“可用”的ExpXXX的話，應(yīng)該要是左右操作數(shù)都需要泛化的。為了進(jìn)一步的重用，可以再泛化操作類型（加減乘）。

這篇文章里我想把重點(diǎn)放在“它可以消除臨對象上”，為了能更“簡單”地說明ET，所以寫的例子很簡陋，不過我想大概的做法已經(jīng)點(diǎn)到了。

完善的做法比較復(fù)雜，所以我認(rèn)為這個庫設(shè)計都用的武器，寫應(yīng)用層邏輯時也許不太會用到？（調(diào)試、維護(hù)都不容易啊……）

下面有一篇文章，從頭開始一點(diǎn)一點(diǎn)地完善這個ExpXXX，講解得非常細(xì)~，每一個改善是為了什么！（不過是日文的，嘿，YESHG，為你準(zhǔn)備的！中文英文的應(yīng)該也有，不過我沒搜到這么細(xì)致的，呵呵，不過對《C++templates》里的例子應(yīng)該也夠看了。）
http://homepage1.nifty.com/herumi/prog/prog81.html#MOTIVATION

PS:
至于那個囧類型，我還沒看到有什么好的做法。因?yàn)橐屪笥也僮鲾?shù)接受不同的表達(dá)式（a，a+b，a+b*c等等等等）才可用，所以操作數(shù)的“類型”不能固定，ExpPlus<I>+ExpPlus<I>==ExpPlus<I>，感覺行不通。你有什么好做法呢？

@OwnWaterloo
呃，不好意思，我是想說“盜版”，呵呵
回想，DB 確實(shí)容易聯(lián)想成 DataBase，那這句話就不好理解了……
It's my fault :)

@non
是有聽這么說的。
不過我總覺得：不鼓勵或是要求禁用 STL 的組織，肯定得要有牛人實(shí)現(xiàn)一套更合適于他們工程的基本類庫，也許他們只是不想要通用的 STL 實(shí)現(xiàn)，但 STL 做的那些事，始終還是需要有“人”來做的。

話說 VC6 還真有點(diǎn)像 IE6 ，擁有極高的使用率，但又不能完全支持“標(biāo)準(zhǔn)”，呵呵，不過 VC6 可以原諒，畢竟開發(fā)的時候 C++ 標(biāo)準(zhǔn)還沒出臺嘛……

唉，托 D 版的福，我可是每發(fā)布一個新版本就立即升級的，呵呵，不過在公司做項目又沒辦法了，得聽公司技術(shù)決策者的，呵，而我們公司那個大牛，MS 習(xí)慣 VC6 ……。

我也很期待 C++0x 呢，對 C++ 很有感情，哈哈

對于
【沒有右值引用，也可以消除很多臨時變量，只是編程很復(fù)雜……】
是啊，但通過這些途徑，完成了一些“目標(biāo)”之后仍然會覺得心中有缺憾，不能用最優(yōu)雅的方式解決問題的時候總會不舒服，
就像 Expression Template 被開發(fā)出來，我想也是人們想有效率，又想直觀的結(jié)果吧……

PS:
您還真是快啊~~我這才發(fā)布，你就來了。神仙~

謝謝你的提醒啊~！
呵呵，這兩天跑去看 WinDbg 的擴(kuò)展命令去了，企圖看能不能通過寫 WinDbg 的擴(kuò)展來達(dá)到目的……有點(diǎn)頭大的說，哈哈。

RednaxelaFX 這個“家伙”也是個神人，我在 JavaEye 上第一次發(fā)表這篇文章的時候就有他的回復(fù)，相信是同一個人，嘿嘿。（他在 JavaEye 上有關(guān)于 JavaScript 運(yùn)行機(jī)制的文章，看得出是很有幾把刷子的）

跑來跑去，發(fā)現(xiàn)世界挺大，圈子確挺小，哈哈哈哈 :P

嗯嗯，是夠長的，明天早起好好看，嘿嘿！！

PS:
>>你本來寫的是【quote】吧？ cnblogs確實(shí)很偏心，cppblog確實(shí)是穿小鞋的……
確實(shí)是的，唉……
這段時間在通過 CSS 和 JS 腳本在配置 cnblogs 的博客，已經(jīng)比較滿意了，嘿嘿。

@OwnWaterloo
是的啊，正好我也在“回味”，哈哈，準(zhǔn)備作為那篇 SFINAE 隨筆的補(bǔ)充，加一些 enable_if 的筆記……

對于 enable_if 的還有一個比較舒服的功能點(diǎn)是：
boost::disable_if<boost::is_class<T>, DataFromFile&>::type
這個可以放返回值的位置上生效，并且讓條件滿足時使用DataFromFile&作為返回類型，其它情況下讓它 Substitution fail，而不對程序產(chǎn)生“負(fù)面影響”。

真是非常體貼啊，因?yàn)樵谶@個地方，運(yùn)算符重載的參數(shù)個數(shù)是有限制的，不能隨意增加，所以在這里不能直接在參數(shù)表中加 T::* p = 0 之類的東西來運(yùn)用 SFINAE。

>>問題就在于這個前提是沒有保證的。編譯器處理尾調(diào)用時可以使用jmp而不用call。這種情況在msvc和gcc上都存在。
哦哦，原來還有這種情況，呃，如果是在 debug 模式下，優(yōu)化全關(guān)呢？嗯，找個時間我再也看看。

>>或者其他profile工具是怎么做的？
這倒是，以前沒想到這個可以做參考呢，嗯，謝謝提醒。


真是獨(dú)學(xué)而無友，則孤陋而寡聞。

PS:
一連兩天看到你搶占沙發(fā)長篇回復(fù)，果然是神人啊……
什么時候我夠格能和你“論戰(zhàn)”一番而后雙方受益，倒是可以“含笑九泉”了，:)

學(xué)習(xí)中……

@OwnWaterloo
調(diào)試器沒有符號表的情況下應(yīng)該也能工作，但給出來的信息是“人類不可讀”的。

一直在找一種方法，希望能實(shí)現(xiàn)這樣的需求：
給出兩個斷點(diǎn)，當(dāng)程序停在第二個斷點(diǎn)的時候，希望得到在之期間被調(diào)用過的函數(shù)的列表（按時間順序）。
當(dāng)然，希望這個方法是非侵入性的。
棧信息顯然是不夠的，某一時刻的棧信息只有被斷點(diǎn)函數(shù)的上層函數(shù)信息，但可以肯定的是每個函數(shù)調(diào)用都會有壓棧出棧，能不能設(shè)置一個類似“勾子”的東西，在CPU進(jìn)行壓棧的時候記錄下某些信息呢？

@OwnWaterloo
謝謝推薦，說起來，C++ 的書讀了不少，不過 BS 老爺子的《the c++ programming language》還真是沒看過……慚愧，回頭找來啃一啃。
《標(biāo)準(zhǔn)C++輸入輸出流與本地化》這本書看了前兩章都看不下去了，實(shí)在有點(diǎn)無趣，倒是《C++ standard library》中IO部分看幾回，但本地化還是沒搞明白。

PS:
說到 log 模塊，覺得還是蠻有用的，就現(xiàn)在手頭上做的項目來說，如果沒有這東西，所有模塊的 log 信息不受任何控制的話，光是這些 log 的通信就能把機(jī)器卡死（因?yàn)闄C(jī)器與PC的是串口連的）……
覺得對于大一點(diǎn)的軟件（雖然我只接觸了一個）來說，系統(tǒng)自身的調(diào)試機(jī)能和控制都蠻重要。