这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
一个编程任务只有在它不可能的时候才有趣，那是在你说服自己能够成功解决它之前。
我想，这就是为什么我的许多项目都在“to_be_continue”文件夹中完成了一半。
其他回答
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
控制反转并不能消除依赖关系，但它确实很好地隐藏了依赖关系。
缺陷和增强请求是相同的
Unless you are developing software on a fixed-price contract, there should be no difference when prioritizing your backlog between "bugs" and "enhancements" and "new feature" requests. OK - maybe that's not controversial, but I have worked on enterprise IT projects where the edict was that "all open bugs must be fixed in the next release", even if that left no developer time for the most desirable new features. So, a problem which was encountered by 1% of the users, 1% of the time took precedence over a new feature would might be immediately useful to 90% of the users. I like to take my entire project backlog, put estimates around each item and take it to the user community for prioritization - with items not classified as "defect", "enhancement", etc.
继承是邪恶的，应该被摈弃。
事实是，在任何情况下，聚合都更好。静态类型的OOP语言不能避免继承，它是描述方法想从类型中得到什么的唯一方法。但是动态语言和鸭子类型可以没有它。Ruby mixins比继承强大得多，也更可控。
Visual Basic和c#都不能胜过对方。除了一些语法和格式之外，它们几乎是一样的。
