Harry's blog

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, 請仔細想想, 是否真要這麼做才能達到你的要求.