Harry's blog

vc8 下安裝 boost 1.35

按照 boost 1.35 的 getting start 安裝, 只得到 release版的 dll library. 參照 bjam --hlep 後, 用以下指令可以得到完整的結果.

1. 解壓縮boost.zip 到 BoostRoot
2. build bjam : 執行BoostRoot\tools\jam\src\build.bat, 產生執行檔 BoostRoot\tools\jam\src\bin.ntx86\bjam.exe
3. 將 bjam.exe 複製到 BoostRoot
4. 開啟 Visual Studio 2005 命令提示字元
d:>cd BoostRoot
d:\BoostRoot>bjam --build-type=complete --toolset=msvc --prefix="d:\boost_output" install

完成後可在 d:\boost_output 目錄中看見所有的 include 及 lib 檔案
完成後可移除 BoostRoot\bin.v2 暫存目錄

繼承的二三事

熟悉c++的人, 都知道要儘量謹慎使用多重繼承. 在Scott Meyers 的 effective c++(3e) Item 40有相關的說明. 那單一繼承呢?

STL 之父Alexander Stepanov 在這裏這麼說, "I think that object orientedness is almost as much of a hoax as Artificial Intelligence.", 對喜好OO的人來說, 一時還真不能接受. 但看看STL, 除了 iostrem, 幾乎看不到繼承. 在同篇文章中, 他評論java時, 也曾提過, java 保留了他不會用到的c++功能(繼承,virtual), 卻移除了他認為有用的功能.

再看看 Bjarne Stroustrup 怎麼說 "You try not to overuse inheritance. When you do use inheritance, you try not to use to overuse multiple inheritance. And when you do use multiple inheritance, you try to avoid the more complicated variations. "
也許有些人會覺得 A. Stepanov 的話太偏激, 但綜合以上兩位大師的話, 至少在使用繼承前, 要謹慎考慮一下是否有別的替代方法. 就像你會謹慎的使用多重繼承一樣. 多重繼承對Java而言, 是種被拒絕的壞味道. 而對Bjarne 來說, 許多c++的特性(如多重繼承), 是為了讓c++能支援多重編程風格. 你可以選擇使用與否, 但在某些特定的狀況下, 少了這個特性, 將無法寫出簡潔明確的程式碼. 而上面他的這段話, 相對也暗示了繼承的謹慎使用.

問題是這個繼承的謹慎使用, 標準是訂在每個人自己心中. 繼承法則大部份人都知道, 表示" is-a" 用public inheritance , 表示"has-a" 用delegation , 表示 "is-implemented-in-terms-of" 儘可能用delegation , 不能時再用 private inheritance.
註 : aggregation,composition, delegation, layering, 指的是同一件事.
is-a 參見 Liskov substitution principle

而遵守這些原則, 仍然有可能使用到不好的繼承. 這裏說的不好的繼承, 並不是說繼承原則用錯了, 而是說在大型系統中, 這樣的繼承體系, 可能會喪失一些彈性及效能. 只是在大部份人面臨的開發環境中, 這種缺點不容易被發現, 而繼承這個方便的優點, 卻是每個人都知道的.

這個標準尺很難拿捏, 有機會再提幾個例子, 先收工了.

c++ strings

經常在無意間的討論中, 會有人提到對 std::string 的一些看法. c 語言底子深厚的人, 常無法擺脫對 char* 的熱愛, 覺得std::string的效能不佳. 慣用java的人, 又嫌std::string 的內建函數太少, 使用起來又常得借用c的字串函數, 不夠方便. 但從反方向看, char* 少了安全性, 而java 少了效率. std::string好像介於兩者中間?
真的是這樣嗎? c++ 是如何面對這種安全性及效率的取捨呢?

標準答案是, 兩者都不能少

而這種"又要馬兒跑, 又要馬兒不吃草"的要求, 正是c++存在的最大意義. 於是許多對string 的最佳化技巧陸續被提出來. 如cow(copy on write), 又如避免動態分配記憶體, 到未來tr2提案書中的支援"move sementics" 的 string algorithm , 針對各種效率不彰的指控, 這些方法都一一的提出解答. 但這麼多種方法, 使用者如何決定用那一個呢? 又日後如何維護如此多種不同設計的strings ?
有一個不錯的選擇 : flex_string by Andrei Alexandrescu (Loki)

這是一個 "policy based"的string template, 你可以依據不同需求, 用template產生你要的string. 例如可以以單/多緒來決定是否使用cow policy, 或是針對小字串使用最佳化的policy, 或使用自己的分配器. flex_sting 完全符合stl標準, 可以輕易取代原有的std::string , 效能馬上提升 !

另一個問題, std::string 內建函數太少. 這基本上不是一個問題, 甚至是優點而不是缺點, 這一點可參考 invarent - 物件導向的精神在維持介面的精簡, 放一堆操作函數在裏面適得其反. 想要操作string , 可以參考 boost 的 string algorithm , 這裏面有著大部份你想的到的字串操作, 如 iends_with, replace .. 等, 安全又好用 : )

有這些免費又高效的程式庫, 下次再用 char* , char buffer[..] , 或是包了一堆介面的string classes, 請仔細想想, 是否真要這麼做才能達到你的要求.

Invariant

The C++ Style Sweet Spothttp

這篇文章中 bjarne stroustrup 提及了何時不該用class, 以及如何判斷一個function 是否適合當作member function. 例如, find_next_sunday 就不適合放在'Date' class中.

這樣的概念, 在STL的 container - algorithm 中得到呼應. 把演算法丟到class中, 並不是物件導向.

在bjarne stroustrup 的"the c++ programming language" 也提過 Invariant(24.3.7.1), 但在這樣的大頭書中, 很多好的概念都隠藏在幾句簡單的話中, 容易被忽略. 常常是在日後某個時刻, 才想起當初簡單的話, 其實並不那麼簡單.....

寫c++筆記, 用來提醒自己, 一些好的概念, 是藏在那些書中.