const，C/C++的第一个败笔

whyglinux

>> 经过越来越多的教训，偶不得不说，const，是C/C++历史上最失败的发明

在 C 语言产生之初，并没有 const 关键字。const 的引入是在 C 标准化的时候。你的这种论调是在怀疑制定标准的那些人以及站在他们身后的无数的程序员们的智慧。如果不是想故意哗众取宠，那就是说这话的人还没有真正掌握 const 的使用，还没有体会到 const 在 C/C++ 程序中的重要作用。

一般是语言初学者或者无甚编程经验的人才会持有这种观点。如果经过一定时间的编程之后还没有在自己的 C/C++ 程序中有意识地使用 const，那真应该深刻自我反思一下。

>> 首先，const侮辱了程序员的智商。C/C++的精髓之一既是，相信程序员的能力，const却说，你程序员是容易出错的，我来帮你编译时把把关。

与机器相比，人是不可靠的，这是人所共知的定论，对此没有什么可值得怀疑的——机器能做以及容易做的事还是交给机器来处理好了。

人们总希望编译器能发现尽量多的程序错误，甚至不惜借助于一些专门的工具。还有，你写的程序可能还要交给他人去测试，明显是不相信你嘛。是不是这样做都会“侮辱”你的智商？

>> const一边侮辱着程序员的智商，一般又出尔反尔，笑里藏刀般给出某种妥协，对了，还有强制类型转换，还有const_cast。

语言中某种特性存在，自然有它的用途，但是并不是说你一定要使用它。const_cast 就是这样的：可能在你的程序中永远都不会用到它；但是假设你用到的一个库函数是类似这样的 int my_strlen( char* s ); 不规范声明，要用它来求 const char* p; 这样定义的 p 指向的字符串的长度，const_cast 就会派上用场了（当然，也可以用强制转换）。

>> 你看到的是const，未必是const的。

你想说的是未必是 constant （常量）或者不可改变的吧？确实是这样的，有什么问题吗？

>> 其次，const严重削弱了编写C++代码的乐趣。

我承认你后面说的问题确实存在，它们可视为引入 const 之后产生的“副作用”。const 就如同现实中的药，当它有疗效的时候人们就会使用它，即使它有些副作用。何况 C/C++ 中的 const 带来的“效益”远远大于它的“副作用”，所以它被引入了。

>> const，你就不能安静的移出C/C++标准吗？

不能。因为那样做会因小失大，智者不为也。

与其写这样观点狭隘的文章，建议你以“如果 C/C++ 中缺了 const 会怎样”为题深入探讨 const 一番，写出一篇值得称道的好文章来。如此幸甚。

whyglinux

继续提出我的看法，很多观点可能与你相左。

>> 的确，我毫无疑问的可以怀疑前辈们的智慧，我毫无疑问的认为，前辈高人不可能意识到C/C++的未来会向什么方向发展。

怀疑一切是你的自由。我们都不是算命先生，没有必要给C/C++算命，只要知道并看到它们仍然在不断发展、仍然被人们广泛使用着就可以了。

>> 前辈高人们也许意识不到，宏定义会成为将代码变成难于移植的一砣乱麻的罪魁之一

之所以难于移植是因为名字冲突吧。人们在实践中早就发现了类似的问题，也对此提出了一些对策。但是无论怎样，在 C 程序中由于共用一个全局空间，所以名字冲突的可能性始终是存在的；直到 C++ 中引入了 namespace 的概念之后，名字冲突的问题才算得到了彻底解决。

>> 前辈高人们也许意识不到，与其使用宏定义包含头文件，不如增加一个#include_once语句加快编译速度

其实这两种方式不会带来编译速度上的差别。

>> 前辈高人们也许意识不到，引以为豪的template类型推导，将无数的代码变成了write only, 难以维护

你的意思是说 C 代码至少比 C++ 容易维护了？

其实能否写出维护性好的代码取决于人，而不是使用的语言。

>> 我宁愿相信，惯性的力量是强大的，C++为了维护C的需要，不得不保留了const关键词。可是发明C的智者们，又哪里能想到C++未来的苦衷。

可能出乎你的意料之外：C 中的 const 关键字是从 C++ 借鉴过来的（可参见 C99 Rationale 的 6.7.3 Type qualifiers 一节）。

>> 任何对权威的质疑，用你这个论点来说都是行不通的。

质疑也要摆事实讲道理。你只讲了 const 的负面，然后据此提出取消 const，而对 const 带来的益处一字不提，这样的质疑在行家眼里又有多少说服力呢？

>> 持有你的这种论调的人，既是盲目相信权威

这话打击面大了点。const 带来的益处是明显的。至于你所提到 const 的缺点，在写程序时多拷贝几次，很容易就能解决。

>> 如是，C不会有发展，C++也不会有发展，世界也不会有发展。

作为写程序的人，我必须得首先学好用好 C/C++。至于语言的发展问题，也只是关注一下而已。

>> 不知道权威们是不是相信权威而从不自我否定呢？

谁都有自我否定的时候。但是对于 const，我敢断言 C 或 C++ 标准委员会的权威们没有一个人会赞同把它从标准中去掉。

>> 做一件事情，要么不做，要么做好。

这是做事的好的态度，但是事情能否做好就另当别论了，很多时候很多情况下是不以个人意志为转移的。

事物都是矛盾的统一体，在带来好处的同时也必然会产生一些不利因素。如何扬长避短才是程序员运用语言之道，而不是一味地排斥某种语言特性。

>> const的缺点在于，还可以用某种方式违反，比如const_cast。

如果使用了 const_cast，那么此处代码正确性的保证就由编译器移交给了程序员，程序员清楚这样做的意义，编译器认可这种转变（不再出现编译错误）。这样做是缺点吗？

>> 在考略兼容性的情况下，的确很难，不过我的一个美好的愿望了。

前面已经说过，不是与 C 的兼容性问题。

whyglinux

原帖由 wwwsq 于 2008-1-29 11:54 发表
用const的人是吃饱了撑的。给自己找麻烦，也给别人找麻烦。

出于历史原因，很多函数接口里面有const，这没办法。这已经够烦的了，别再添烦了。

比如strcpy()函数的第二个参数，就是带const。它就是带const的，已经是陈年旧账，你有什么办法？又改不来。

从 C 的历史来看，它总是在不停地找“麻烦”。

最初的 C 语言并没有 const 关键字，所以那时候库函数中也没有 const 来修饰参数。

1. char *strcpy(char * s1, char * s2);
   

复制代码

后来随着需要，有的编译器的实现增加了 const 供使用，并且被 C 的第一个标准 C89 所接受，从此之后标准库函数中该加 const 的地方才都加上了。这一改动也要求用户在自己的代码中注意 const 的使用；该用的地方不用，会给其它使用者带来不便。

1. char *strcpy(char * s1, const char * s2);
   

复制代码

在此之后，人们还不满足，新的 C 标准 C99 又增加了 restrict 关键字，所以你可看到 strcpy() 的声明已经变成了这样：

1. char *strcpy(char * restrict s1, const char * restrict s2);
   

复制代码

[ 本帖最后由 whyglinux 于 2008-4-10 21:47 编辑 ]