C++ Frequently Questioned Answers (2009)
C++ certainly has flaws - but it also has intentional design choices, which are important for achieving its goals. Also, as others have mentioned - much has improved since 2009.<p>To make this concrete, Let&#x27;s go over the &quot;C++ defects&quot; summary appearing at the link, before the individual &quot;frequently-questioned answers&quot;.<p>&gt; changing the private members of a class requires recompilation of the code using the class. When the class is used to instantiate member objects of other classes, the rule is of course applied recursively.<p>This is mandated by two of C++&#x27; language design goals:<p>1. Performance of compiled C++ code: This recompilation is necessary for exploiting optimization opportunities involved the altered private members. In fact, these days, compilers goes beyond even that situation: _linking_ code may trigger partial re-compilation without any changes to the source.<p>2. Zero-overhead abstractions: Having a private member should not in itself cost you in terms of performance.<p>However, we can make the class implementation opaque (e.g. using the PIMPL idiom: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;tags&#x2F;pimpl-idiom&#x2F;info" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;tags&#x2F;pimpl-idiom&#x2F;info</a> ) if we want&#x2F;need to.<p>&gt; Outstandingly complicated grammar<p>C++ is guilty as charged here! It even has a semi-idiom named the &quot;most vexing parse&quot;: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Most_vexing_parse" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Most_vexing_parse</a><p>But there is an excuse, which is: Backwards compatibility. First, with C and C&#x27;s syntax; then, with earlier versions of the language. Fixing the complicated syntax would break all existing C++ versions. So, they don&#x27;t do it.<p>&gt; No way to locate definitions<p>The fix for this is now part of the language: Modules. Unfortunately it will take time before these are widely-enough adopted.<p>&gt; No run time encapsulation...  C and C++ are not designed to run in managed environments<p>This is again necessitated by the performance requirements. Run-time encapsulation would mean slower code, sometimes much slower.<p>Also, such encapsulation would mean there would be room for another C++-like language, below C++, without this encapsulation... and a goal of C++ is not to leave such room.<p>Luckily, in recent years we have undefined behavior sanitizers in compilers, which catch a lot of these cases.<p>One should also remember that languages with managed runtime environments often have exceptions to the rule, i.e. unsafe&#x2F;unmanaged sections (unsafe in Rust, JNI in Java).<p>&gt; No binary implementation rules<p>Sorry to have to harp on this, but platform-specific ABI is another necessity of performance. Still, C++ has a long way to improve in this respect, e.g.  <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;58339165&#x2F;1593077" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;q&#x2F;58339165&#x2F;1593077</a><p>Recently, stack traces have been introduced into the language, and in C++23 they might be available by default when throwing exceptions; see: <a href="https:&#x2F;&#x2F;wg21.link&#x2F;p2370r2" rel="nofollow">https:&#x2F;&#x2F;wg21.link&#x2F;p2370r2</a><p>(I may continue in another post or extend this one.)