I don't want to outright dismiss this piece as "argument bait", but it is essentially just a bunch of assertions on what other people should do with virtually no rationale and a bunch of shade thrown around deliberately. Sure, we all like to have a good argument, and C++ is an easy target, but this seems wholly unproductive from the get-go. If there was any intent of <i>convincing</i> others then this isn't how to do it.<p>I would also like to know who or what the "Orthodox C++ committee" is. A search only gets you this exact gist. Is the author himself the committee? That really doesn't put this piece into a better light.
Interesting idea, pity about the name. There's a vaguely similar effort with a similarly poor choice of name, <i>Clean C</i>, which is guaranteed to compile as both C and C++ with the same behaviour (provided there's no undefined behaviour or platform-specific behaviour). [0][1]<p>> Exception handling is the only C++ language feature which requires significant support from a complex runtime system, and it's the only C++ feature that has a runtime cost even if you don't use it<p>I don't think that's true. I believe that if you enable RTTI you pay for it even if you don't use it, which is why it's banned in the LLVM codebase. [2]<p>> Don't use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)<p>I believe this is still supported, but is officially deprecated, for what that's worth. [3]<p>[0] <a href="http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.neutrino.prog%2Ftopic%2Fhat_Clean_C.html" rel="nofollow">http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%...</a><p>[1] <a href="https://stackoverflow.com/a/9695020/" rel="nofollow">https://stackoverflow.com/a/9695020/</a><p>[2] <a href="https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions" rel="nofollow">https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-o...</a><p>[3] <a href="https://stackoverflow.com/a/13643019/" rel="nofollow">https://stackoverflow.com/a/13643019/</a><p><i>edit</i> Correction: It's called <i>Clean C</i> not <i>Clean C++</i>
This is somewhat exaggerated, especially because while there are several poorly designed areas in C++ and the STL, it's not all that bad and it can lead to safer, less fragile code than the C equivalent with less effort (but arguably, more skill is required in order to learn and proficiently use C++). It can even be faster than C in the hands of a skilled developer that knows where and how use the right features.<p>It doesn't hurt that the STL is extremely optimized, and often provides you tools that accomplish what you cared about without lots of the gotchas and pitfalls you're almost certainly doomed to fall for if you're not aware of their existence. Almost every single C project I've seen (including some of mine, I've to admit) end up involuntarily reimplementing some basic algorithm or container, and most often than not it ends up being less efficient, or unnecessarily using the heap.<p>One thing I think most people largely misunderstood is exceptions; they're actually totally fine if used in _exceptional_ circumstances, as if they were some kind of softer assertion, when you expect some kind of contract to be always true, but calling abort is just too unreasonable. This is basically the same approach Rust and Go use with panic(), and in both languages this facility by default causes the runtime to unwind the stack, as with C++ exceptions.<p>I think lots of people have been turned off by certain bad designs in older C++ revisions, where exceptions where indiscriminately used for error handing. They were a nightmare to use right, and the lack of helpers like unique_ptr made exception safety very hard.<p>Modern practices, an arguably better language after C++11 and guidelines/libraries such as the GSL vastly help in mitigating most of these issues, as long as people actually stick to them (i.e., no C style code without RAII).<p>I may also argue that the whole "C++ exceptions are expensive" argument is 100% moot in 2020, I've been running code on microcontrollers with half a megabyte of ram with them turned on and they add an almost insignificant amount of overhead; they only cause a small amount of binary bloat, but that's nothing compared to the size of certain modern libraries (and storage is cheap).
Very dubious stuff here. For example:<p>> and it's the only C++ feature that has a runtime cost even if you don't use it – sometimes as additional hidden code at every object construction, destruction, and try block entry/exit, and always by limiting what the compiler's optimizer can do, often quite significantly.<p>C++ doesn't do "hidden code" - "if you don't use a feature you don't pay for it" is one of the bedrock principles of the language.
This is rather awful.<p>The concept isn't terrible necessarily, but the execution and condescension sure is. And some of the rules are just pointlessly argumentative. Such as refusing to use <cstdio> and instead using <stdio.h> - those are officially documented to be different things with different behaviors. Blanket banning one of them doesn't improve simplicity, especially if you're blanket banning the "wrong" set of headers. Unless the goal is to also ban namespaces, but that's not called out as such (and namespaces are one of the least contentions C++ features - everyone seems to like them well enough).<p>Or similarly:<p>> Don't use anything from STL that allocates memory, unless you don't care about memory management.<p>So don't use std::vector? Or std::unordered_map? Or std::string? These are all perfectly fine classes, banning them makes no sense at all. Maybe the goal was to ban "hidden cost" classes like std::function, but rolling your own 'C-style' is a <i>hell</i> of a lot more complex & error prone (raise your hand if you've seen a C pointer callback that forgot to have a void* context or a mismanagement of said void* context...)
I thought this was a good point:<p>> Don't do this: <a href="http://archive.md/2014.04.28-125041/http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/design.html" rel="nofollow">http://archive.md/2014.04.28-125041/http://www.boost.org/doc...</a><p>Maybe he is looking to use golang?
I find the Arduino C++ "dialect" being quite orthodox. Maybe a bit too rigorous, since it doesn't use the STL (which is mostly quite fine). I personally don't like C++ code which exploit all Turing completeness of the templating language. Code using such libraries can get a horror to debug on cryptic compiler error messages.
I'm sorry, but the STL, especially the Stepanov designed parts are brilliant pieces of software. Written in a style unlike anything else. Generic programming is often misunderstood and that's a damn shame.
Orthodox C++ echoes the old "Embedded C++" scam.<p>In that case, the impetus was to dress up having failed to implement templates, exceptions, and other "new" language features, typically as a result of budget cuts.<p>In this case, it appears to be, rather, to avoid learning anything new.<p>Make no mistake: code written to this, or any old-school subset, is Bad Code. Features are not added to C++ on a whim. They are added because they make programming in new C++ a better experience than old C++. New C++ code is faster, safer, smaller, less bug-prone, and more fun than old C++. C++20 is much more fun than C++17, which is better than C++14, which filled out lots of features from C++11.<p>Do not trust anyone suggesting any virtue in more C-like C++ code, or in actual C code. We left those behind for reasons.<p>C++23 will be better than C++20.
Reminds me of <i>JavaScript: The Good Parts</i> by Crockford:<p><a href="https://www.youtube.com/watch?v=hQVTIJBZook" rel="nofollow">https://www.youtube.com/watch?v=hQVTIJBZook</a><p>Strip away an older language's bad features. You end up with a sub-language with the advantage of portability and better maintainability.<p>The problem can be deciding (and agreeing on) which language features are good and which are bad.
Terry Davis did it first haha.
<a href="https://en.m.wikipedia.org/wiki/TempleOS" rel="nofollow">https://en.m.wikipedia.org/wiki/TempleOS</a>
I just use Go (golang) instead, whenever I can<p>Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection<p>Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.)<p>Go puts essential C idioms directly into the language (pointer/length is formalized as slices, packages are part of the language instead of just being naming convention, etc.)<p>The longer I used C++, the more I despised it. I used C++ for 11 years and I literally hate the language. But C has always remained a pleasure, and Go is a continuation/modernization/enhancement of that<p>Go is mature, stable, widely-used, well-supported, well-understood, etc., so it's fully mainstream<p>If you like C, you will love Go