C++混到现在这个尴尬的地位，和高高在上的C++标准委员会有极大的关系。这帮人一是行动缓慢，二是沉迷于语法细节，以繁琐为乐。我怀疑这个委员会是不是欧洲人占主体所以才这样。美国人采用的是实用主义哲学，以简单好用为追求，比如C, 比如TCP/IP; 欧洲人以精确严谨为追求，不在乎用户接不接受，比如C++,比如ISO-OSI七层协议。

复讨论一个特性的得失应当看它的机会收益

家园

c++真是个大酱缸，引入太多特性，太臃肿了

复 C++ ABI不兼容确实是个大问题，但是不光是重载引起的

家园

同意，c++标准委员会运作模式与社区模式区别太大

复替C++说几句话

家园

关于C++和脚本语言其实没什么好讨论的

两者根本就不是一个层面上的东西，一个是做应用的工具，一个是做工具的工具。数控机床好，削个苹果能有小刀顺手么？小刀削苹果快，给个铁块能削出个小刀来么？

程序员应该跳出语言的局限，适当的时候采取适当的工具完成任务。

复 C++过度设计了

家园

说点不同意见

重载，尤其是运算符重载，更尤其是圆括号()的重载是C++的一大优势。Functor的运用1)使得callback非常容易实现，和扩展。与C语言的函数指针相似，对被调用函数名称无限制，而更进一步增加了类型安全。2）与模板相结合，使得C++有能力与时俱进，在Function Programming流行的今天继续占有一席之地,比如boost.phoenix。boost.spirit更是运算符重载的杀手级运用，到目前为止我还不知道有哪种语言可以这样高效，无缝的内嵌表达式解析器，而且接口如此简单parse(target range，grammar，output).

复 C++ ABI不兼容确实是个大问题，但是不光是重载引起的

家园

内存布局不规定现在看来

内存布局不规定现在看来，也许会是好事，使得在C++适应并行时代少了一些羁绊。

复说点不同意见

家园

我也并非完全反对重载

首先，我反对的是在所有域中不受限制的隐式重载。从实用主义的角度出发，类成员函数的重载是可以接受的，因为类成员函数相对于C来说是新的，可以在上面附加其他的功能，而且，类成员函数明确定义在一个域中，无论是功能上还是在代码上它们都是聚集的，并且限制在某个范围内，所以重名也不会引发理解上的问题。但是，对一个global scope里面的函数，隐式的重载使得其编译出来的代码和传统的C不兼容，而且会引发理解上的困难。例如：

#include <foo2.h>

void foo(float bar) {}

foo(1);

请问这个foo调用的是哪一个函数? 看起来它应当就是离它最近的那个函数，这理应是最简单的行为，但是C++中，如果foo2.h中有另一个void foo(int)，那么它会调用另一个函数。这要求程序员和IDE都要做全局的分析以后才能知晓。如果我们禁止隐式重载，让重命名foo函数变为错误，而引入一个关键字overload做显式重载，那么会怎么样呢：

#include <foo2.h>

void foo_f(float bar) {}

overload foo foo_i;

foo(1);

不动的部分保持了和C的兼容性，foo_f, foo_i都被直接地暴露到名字表中，使得我们可以去掉export关键字，而且增加的overload关键字在程序中显式地标识出重载表，考虑到它可以重复声明，因此可以在离调用最近的地方重声明来方便程序的理解。同理C++中的exception等都可以用类似的方法加入，而不需要修改整个语言。这样做的一个额外的好处就是如果程序员坚持老的方式，他不需要重新学习什么东西，不需要改变自己来适应语言的变化。

其次，我反对C++现在这样的运算符重载。我认为Python的运算符重载方式更为优越。对于一个类，除非用operator关键字声明，除非在C++中使用运算符，否则一个程序员无法用别的方式重新定义和使用这一功能。所以C++的书里面必须单独辟出一章来讲运算符重载。其实运算符重载只不过是成员函数重载的一种特殊形式。如果我们强制规定类的__exec__方法对应operator ()，那么，程序员就不需要额外学习运算符重载，他可以持续地按普通成员函数的方式定义和使用__exec__。而且，对于非C++的语言，也可以通过调用__exec__方法来复用C++程序员的成果。

Boost.spirit这样的模板库，我还是那个看法，看起来很精致，很美，但是不实用。在缺乏编译过程的调试工具的现状下，使用复杂的模板库，其开发时间会远远超过使用非模板库。而且就算神的代码一次性正确又如何，编译时间都会使得基于它的代码缺乏竞争力。很多东西都不需要我们来批判它，它会自然地被时间淘汰的。

通宝推：铁手,

本帖一共被 1 帖引用 (帖内工具实现)