关闭

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

973人阅读 评论(0) 收藏 举报

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

 

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

 

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

 

不优雅的代码:

 

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

 

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

 

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

 

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

 

发明轮子:

 

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

 

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

 

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

 

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

 

 

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

推荐!

 

 

 

 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:25233次
    • 积分:386
    • 等级:
    • 排名:千里之外
    • 原创:8篇
    • 转载:0篇
    • 译文:0篇
    • 评论:52条
    文章分类
    最新评论