Posted on May 30th, 2010 at 16:11 by fr3@K

想加入這篇 解读google C++ code style谈对C++的理解 的討論. 不幸由於不明原因, 一直被系統認為是廣告 (圖中紅字部份):
先留個底, 再看看該/能怎麼辦吧.
ps. cppblog 帳號申請中, 也許有帳號就沒這問題了吧? 不過, 看起來申請帳號要經過人工審核…
(more…)

想加入這篇 解读google C++ code style谈对C++的理解 的討論. 不幸由於不明原因, 一直被系統認為是廣告 (圖中紅字部份):
先留個底, 再看看該/能怎麼辦吧.
ps. cppblog 帳號申請中, 也許有帳號就沒這問題了吧? 不過, 看起來申請帳號要經過人工審核…
(more…)
When you lie to your compiler, don’t be surprised to get results those differ from what you expect.
In this case, the coder promised his/her compiler the value of “value” won’t be changed, as it was declared const.
Therefore our best friend (yes, the compiler) who trusted the coder, thought “hey, I could cache this value in a register and not fetch it from RAM every time I reference it”, i.e. optimization.
If we change the code in the link slightly, so that function funcC would print *value before the assignment, one would see that the value of *value had actually been modified by function funcA. However, the modification was not visible in main, because the compiler was lied to as the coder explicitly told it that there would be no modification to value.
In the body of function funcC, though value was declared as a pointer to const instance, the compiler was smart enough to know it was lied to. There was a const_cast and a assignment, therefore, the modification to *value was reflected in the output.
In a recent post of Scott Wheeler’s – C and C++ are not the same language. He talked about differences between C and C++, and applications of different programming languages (C, C++, Java, Ruby) in his company.
In the post, Wheeler implemented observer pattern in C, C++ and Java, demonstrating some of his points – including how C and C++ are different from each other, and how C++ and Java are actually more alike.
Though I do agree with Wheeler’s conclusion for the most part, I failed to share his view in C, C++ and Java comparison. IMHO, his observer implementation in C++ is rather old school, or should I say it’s so Java.
Keiko 寫了篇 討論 DSL 的文字. 這篇文字不短, 有層次. 有他說的 “學院派式” 的格調. 讓我有一種在看一份探討輪胎直徑與胎壓以及胎壁厚度之間關係的 paper 的 feel. 相形之下, 這裡寫的東西看起來更像是黑手示範如何補胎換胎的 howto.
好了, 細節不多談, 建議看官移架拜讀. 重點是, 本要在 comment 裏寫 code, 但這該死的 blogger 超難用, 讓我想起當年 從 blogger 離家出走 的原因. 又扯遠了, 回到我想回應給 Keiko 的東西.
(more…)
上一篇寫到 不識貨的我不欣賞 ActiveMQ-CPP “仿 Java” 的 design 哲學. 或許是我太機車了, 畢竟這是主觀的. 一個特定 design 哲學及其產物一定是有好也有壞, 評價的高低端看它的強項是否能被人欣賞, 缺點是否能被接受 (忍受). 今天讓我們來幫 ActiveMQ-CPP 做個 code review, 從 C++ coding 來看看能不能幫 Apache 扳回一城.
(more…)
由於工作需要, 這幾天花了點時間看了 ActiveMQ-CPP 的文件與 source code. 第一印象是 – 這票 Apache 的人會不會太喜歡 Java 了?
(more…)
回應 G++ 尚未支援 extern template? 原文作者的意見:
原來如此,不過的確 header file 跟 implementation file 有時是有分開的必要,那麼,對 function template 來說又該怎麼作比較好?
先認錯一下, 我在該文的回應中數次提到 extern template. 事後我又研究了一下, 是我搞錯了, 應該是 exported template.
兩者為相關但功能不同的 C++ feature.
我的錯誤導致作者把文章的標題改錯了, sorry… 我的回應應更正為:
即便已編譯成 library, 當 library source 內有
extern templateexported template 時, client code 依然需要該extern templatetemplate definition 的 source code 才能 link 到 template 的 instance.
回應 ‘dynamic_cast’ : ‘A’ is not a polymorphic type 原文作者的意見:
Thank you..
其實這個東西以前都只會用,也沒去研究他dynamic_cast怎麼判斷的,而且我都很習慣的在base class加入virtual destructor,所以剛好都沒遇到這個問題 XD
如此不但可減少不需要的 overhead. 更重要的是, 那可能是阻止使用者繼承該 class 的最有效手段之一. (請參考我之前留的 link) 畢竟, 不是什麼 class 都是被設計來讓使用者以動態的方式操作的. 以 C++ Standard Library 為例, 除了 IOStream framework 以及 implementor 偷懶的部份之外, 我還真想不起來那些 class 有 C++ Standard 定義的 virtual destructor.
撇開所謂的 framework, 優秀的/重複使用性高的 class library 的特徵之一就是低相依性. 而繼承正是 C++ 能表達的最大 dependency. 就如一把殺傷力強大的手槍一樣, inheritance 與 virtual 本身並不 evil. 會發揮正面功能或是負面影響, 就要看我們是如何使用這些 C++ 給的武器.
這是一個我想寫很久了的主題, 由於我也搞不清楚的原因 delay 到這個時候. Anyway, here it goes…
(more…)
In a blog post Danny Kalev published earlier this year on InformIT, an example was presented demonstrating how one could write valid but insecure code involving vector and auto_ptr which compiles without any warning, despite other warnings Micorsoft’s recent compilers would’ve issued against standard compliant code. Along with other points he made in the post, Danny suggests Micorsoft doesn’t really care about your code safety. I couldn’t have agreed with him more, and would like to contribute my own analysis (aka. my two cents) in support of Danny’s finding.
(more…)
Except where otherwise noted, COdE fr3@K by
fr3@K is licensed under a
Creative Commons Attribution-Share Alike 3.0 License.