标准库——C++的阿基里斯之踵

说实话，为了解决同样的问题，能不用C++我就尽量不用C++，因为，我觉得C++编程太繁琐了！为什么这样说？且听我慢慢道来。

C++，作为一种程序语言，有着非常精美和简练的语法。和C一脉相承的C++，其简练的语法推卸掉了太多的责任，把绝大部分工作压在了库(library)的身上。这一点，在当时是被广为传颂的优点。“设计一个库比增加一个语言特性更好”，Stroustrup^[Rev01]如是说。确实，看现在流行的C#, Java, Python, Ruby，携数量庞大的类库之威，都照着这条道路坚定地前进，但显然，他们比C++走的更好。

因为，C++标准库的先天不足，不仅使得精美和简练的语法难以造成同样优雅的代码，而且可怜的程序员们还不得不在每个项目中一次又一次地发明轮子——作为选择C++的代价。

不优雅的代码：

这主要是由于顾及安全原因而采取的保护性编程造成的后果。在一波又一波的攻击、木马、病毒的洗礼下，在一个又一个著名的漏洞面前，在大师们的譐譐教导下，我们都知道了strcpy是个非常危险的函数。也知道了strlen有可能使你的程序大门洞开。

于是，我们都学会了传说中的“保护性编程”：

在操作每个字符串的时候，我们都小心翼翼地丈量好它的长度，声明固定大小的缓冲区，然后再仔细检查返回值，随后才安心地继续前进。我们每个人都知道了太多标准库函数的实现细节，从而不得不在我们的客户代码中耐心地避开那些众所周知的缺陷。大概MS也看不下去了，strcpy一干人等在VC++2005中干脆被声明为deprecated，MS建议你使用更加安全同时也不是非常好用的strcpy_s等替代者。

类似的保护性编程还有网络应用程序中，对虚弱的socket类函数的精心呵护……ACE的使用者肯定对此深有体会。

发明轮子：

如果说安全性原因是部分由于C++兼容C所带来的缺陷，标准库的不完善却是不容置疑的事实了。这种不完善是方方面面的：从IO处理、字符串使用，到错误处理策略、线程操控和常用工具类/函数的缺乏，处处让我们的编程捉襟见肘。标准库中难得的亮点就是STL，为我们提供了一套比较稳定且功能足够强大的容器和算法。

还拿字符串来说，C++标准库第二次修订时引入的string泛型类被宣扬成char[]和wchar_t[]的良好替代品。但是，用MFC的人却发现，为了保持和MFC框架的兼容，他们不得不使用CString作为字符串类型；第一次接触ACE的人也会惊奇地发现，Douglas C.Schmidt积极地推荐人们使用ACE_TEXT宏构建字符串，因为这能更好地移植；同样，几乎每个大量处理文本的C++项目都有自己的字符串类，只是为了弥补string的一点点缺陷（比如，string和char*的随意转换就不是一上手就能学会的……）。

不要告诉我说除了标准库，还有这个库，那个库……完全不同的类库风格造成了非常陡峭的学习曲线，同时，我们还不得不注意到这些优秀的库同样在重复制造轮子——为的只是弥补标准库的先天缺陷。当然，最后补一句，boost库的加入也许会使C++标准库声威大壮，但是，标准库能否完全消化风格迥异的库，boost是否能够解决上述问题，还是一个未知数。

如果你从没用过C/C++以外的语言，不妨试试C#，Java，Perl，Python，Ruby……也许你会发现一片新天地。不识庐山真面目，只缘身在此山中。

[Rev01] C++语言的设计和演化，Bjarne Stroustrup著，裘宗燕 译，机械工业出版社，2001。