c++是有史以来最糟糕的编程语言之一。

它具有委员会设计的所有特征——它不能很好地完成任何给定的工作，而且某些工作(如面向对象)做得很糟糕。它有一种“厨房水槽”的绝望，不会消失。

它是学习编程的可怕的“第一语言”。你(从语言中)得不到优雅，得不到帮助。取而代之的是陷阱和雷区(内存管理、模板等)。

它不是一种学习面向对象概念的好语言。它表现为“带有类包装器的C”，而不是一种合适的OO语言。

我可以继续讲下去，但现在就讲到这里。我从来不喜欢用c++编程，虽然我是在FORTRAN上“磨砺”的，但我完全喜欢用C编程。我仍然认为C是最伟大的“经典”语言之一。在我看来，c++肯定不是这样的。

欢呼,

-R

EDIT: To respond to the comments on teaching C++. You can teach C++ in two ways - either teaching it as C "on steroids" (start with variables, conditions, loops, etc), or teaching it as a pure "OO" language (start with classes, methods, etc). You can find teaching texts that use one or other of these approaches. I prefer the latter approach (OO first) as it does emphasize the capabilities of C++ as an OO language (which was the original design emphasis of C++). If you want to teach C++ "as C", then I think you should teach C, not C++.

但就我的经验而言，c++作为第一语言的问题在于，这门语言太大了，无法在一个学期内教授，而且大多数“介绍”文本试图涵盖所有内容。在“第一语言”课程中涵盖所有主题是不可能的。在我看来，你至少要把它分成两个学期，然后它就不再是“第一语言”了。

我确实教c++，但只是作为一种“新语言”——也就是说，你必须精通一些先前的“纯”语言(不是脚本或宏)，然后才能注册这门课程。在我看来，c++是一种很好的“第二语言”。

-R

另一个编辑:(对康拉德)

I do not at all agree that C++ "is superior in every way" to C. I spent years coding C programs for microcontrollers and other embedded applications. The C compilers for these devices are highly optimized, often producing code as good as hand-coded assembler. When you move to C++, you gain a tremendous overhead imposed by the compiler in order to manage language features you may not use. In embedded applications, you gain little by adding classes and such, IMO. What you need is tight, clean code. You can write it in C++, but then you're really just writing C, and the C compilers are more optimized in these applications.

I wrote a MIDI engine, first in C, later in C++ (at the vendor's request) for an embedded controller (sound card). In the end, to meet the performance requirements (MIDI timings, etc) we had to revert to pure C for all of the core code. We were able to use C++ for the high-level code, and having classes was very sweet - but we needed C to get the performance at the lower level. The C code was an order of magnitude faster than the C++ code, but hand coded assembler was only slightly faster than the compiled C code. This was back in the early 1990s, just to place the events properly.

-R

这个怎么样:

垃圾收集器实际上会损害程序员的工作效率，并使资源泄漏更难发现和修复

请注意，我谈论的是一般的资源，而不仅仅是内存。

三元操作符绝对糟糕。他们是懒惰编程的典型代表。

user->isLoggedIn() ? user->update() : user->askLogin();

这太容易搞砸了。修订2的一个小变化:

user->isLoggedIn() && user->isNotNew(time()) ? user->update() : user->askLogin();

哦，是的，只是一个“小改变”。

user->isLoggedIn() && user->isNotNew(time()) ? user->update() 
    : user->noCredentials() ? user->askSignup
        : user->askLogin();

哦，糟了，那另一个案子呢?

user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned() ? user->update() 
    : user->noCredentials() || !user->isBanned() ? user->askSignup()
        : user->askLogin();

不不不不。只需要为我们保存代码更改。别再那么懒了:

if (user->isLoggedIn()) {
    user->update()
} else {
    user->askLogin();
}

因为如果第一次就做对了，我们就不必一次又一次地改变你的垃圾三元组:

if (user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned()) {
    user->update()
} else {
    if (user->noCredentials() || !user->isBanned()) {
        user->askSignup();
    } else {
        user->askLogin();
    }
}

That (at least during initial design), every Database Table (well, almost every one) should be clearly defined to contain some clearly understanable business entity or system-level domain abstraction, and that whether or not you use it as a a primary key and as Foreign Keys in other dependant tables, some column (attribute) or subset of the table attributes should be clearly defined to represent a unique key for that table (entity/abstraction). This is the only way to ensure that the overall table structure represents a logically consistent representation of the complete system data structure, without overlap or misunbderstood flattening. I am a firm believeer in using non-meaningful surrogate keys for Pks and Fks and join functionality, (for performance, ease of use, and other reasons), but I beleive the tendency in this direction has taken the database community too far away from the original Cobb principles, and we jhave lost much of the benefits (of database consistency) that natural keys provided.

那么为什么不两者都用呢?

SQL可以而且应该做得更好。由于其原始规范有限，多年来各种厂商一直在向不同方向扩展该语言。为MS-SQL编写的SQL与为Oracle、IBM、MySQL、Sybase等编写的SQL不同。其他严肃的语言(以c++为例)都经过了仔细的标准化，因此在一个编译器下编写的c++通常可以在另一个编译器下编译而无需修改。为什么SQL不能被更好地设计和标准化呢?

HTML作为浏览器显示语言是一个严重的错误选择。我们花了数年时间通过CSS、XHTML、Javascript、Ajax、Flash等进行扩展，以制作一个可用的UI，但结果仍然不如你的基本厚客户端windows应用程序。此外，一个称职的web程序员现在需要了解三到四种语言才能制作一个像样的UI。

噢,是的。匈牙利符号令人厌恶。

全局变量和/或单例变量本身并不邪恶

我来自更多的系统管理员，shell, Perl(和我的“真正的”编程)，PHP类型的背景;去年我被派去做Java开发工作。

单身是邪恶的。全球人太邪恶了，他们甚至不被允许。然而，Java有像AOP这样的东西，现在还有各种“依赖注入”框架(我们使用谷歌Guice)。AOP就不是这样了，但是DI的东西肯定会给你什么?全局变量。啊,谢谢。