5 ms·

Excellent article! I stopped using C++ completely after completing the meme that is posted near the end, I wrote gazillions of lines of C++ over 20 years, used

Excellent article! I stopped using C++ completely after completing the meme that is posted near the end, I wrote gazillions of lines of C++ over 20 years, used all the gizmos, and then, gradually started to cut down on them, eventually settling on stuff like --no-rtti and --no-exceptions. It's mostly working on the linux kernel and qemu that showed me I could write extremely nicely structured code, in plain C. Very easy to debug, very readable, very quick to compile and run. And then one day I looked at one of my C++ module and told myself I actually didn't /need/ all that jazz of classes, namespaces, constructors etc etc. It could be done as a small .h/.c couple with 2 functions... And that day I started to convert many many lines of C++ to plain C. Because it's /indestructible/, it'll continue compiling and working on /anything/ forever, without having to figure out why the new C++ compiler is throwing you a 10 lines error message just because that codebase is 10yo and isn't up to scratch with the 'new' way of doing things. I DO miss bits of C++, I miss some of the encapsulation it provides, I miss stack-based objects, and funnily enough, I miss exceptions. But I haven't looked back. The other points he makes about 'junior hires' is also very valid, with C++ you could /easily/ have a new guy write completely bonkers code, add subtle bugs that takes days to find, much much later. I had my own horror stories about that, and that's another factor that pushed me over the edge to drop the language.

thestoicattack 8y ago
> the new C++ compiler is throwing you a 10 lines error message just because that codebase is 10yo and isn't up to scratch with the 'new' way of doing things Does this happen? I thought the committee was so into backwards-compatibility that C++ will also work on everything forever.
- 0xcafecafe 8y ago
  I doubt it and would love if the OP gave an example. One of the reasons that C++ suffers from bloat is they always strive to keep backward compatibility.
- buserror 8y ago
  Sure. I remember one. For about a million years, you could declare a naked virtual method with int blah() = NULL; -- perhaps it wasn't /suposed/ to be used like that according to the standard... but it worked, and was used a lot, as it made perfect sense. Then one day, you recompile it and no, it /needs/ to be ZERO and not NULL sorry. But it's just one simple to fix example, in plenty of cases, especially as templates (and especially template instantiations) evolved, the whole thing would come crashing on you. For a while trying to compile templated code on MS, CodeWarrior and GCC was pretty much impossible without deploying ruses that made C preprocessor macros tame in comparison.
  - thestoicattack 8y ago
    Oh, ouch. I never knew about that one. I assume it's an effect of various "#define NULL 0" type things that got stomped by the introduction of nullptr in C++11?
  - int_19h 8y ago
    As you yourself admitted, it was not the standard way of doing things. Ever since the first ISO C++ standard, the syntax was =0. And it was never guaranteed that NULL (which is a macro) expands to just plain 0. So even back when it "just worked" for you, chances were good that it only worked on that one implementation that you had, and would've broken if you tried to use a different compiler. Judging by your mention of CodeWarrior, this all sounds like war stories from pre-standardization days (and of course it still took a while after ISO C++98 was published, for implementations to actually adopt it).
    - kps 8y ago
      > And it was never guaranteed that NULL (which is a macro) expands to just plain 0. True, but is was guaranteed that NULL expands to “an implementation-defined C++ null pointer constant” (C++98 §18.1), where a ‘null pointer constant’ is “an integral constant expression (5.19) rvalue of integer type that evaluates to zero" (C++98 §4.10). So while it didn't have to be just plain (literal) 0, it did have to be a compile-time constant integer 0, which is otherwise just as good unless you're doing macro magic. (This differed from C (ANSI era), in which a null pointer constant can alternatively have type (void*), and often does.) The fact that a pure declaration requires a literal single character ‘0’ (rather than 0) is just one sad example of C++'s ad-hoc irregular overloading of things to mean different things.
- jandrese 8y ago
  All of my old C++ code broke when namespaces were standardized. Most of it could be fixed with "using namespace std;" at the top, but it wouldn't compile out of the box.

thestoicattack 8y ago

> the new C++ compiler is throwing you a 10 lines error message just because that codebase is 10yo and isn't up to scratch with the 'new' way of doing things Does this happen? I thought the committee was so into backwards-compatibility that C++ will also work on everything forever.

0xcafecafe 8y ago
I doubt it and would love if the OP gave an example. One of the reasons that C++ suffers from bloat is they always strive to keep backward compatibility.
buserror 8y ago
Sure. I remember one. For about a million years, you could declare a naked virtual method with int blah() = NULL; -- perhaps it wasn't /suposed/ to be used like that according to the standard... but it worked, and was used a lot, as it made perfect sense. Then one day, you recompile it and no, it /needs/ to be ZERO and not NULL sorry. But it's just one simple to fix example, in plenty of cases, especially as templates (and especially template instantiations) evolved, the whole thing would come crashing on you. For a while trying to compile templated code on MS, CodeWarrior and GCC was pretty much impossible without deploying ruses that made C preprocessor macros tame in comparison.
- thestoicattack 8y ago
  Oh, ouch. I never knew about that one. I assume it's an effect of various "#define NULL 0" type things that got stomped by the introduction of nullptr in C++11?
- int_19h 8y ago
  As you yourself admitted, it was not the standard way of doing things. Ever since the first ISO C++ standard, the syntax was =0. And it was never guaranteed that NULL (which is a macro) expands to just plain 0. So even back when it "just worked" for you, chances were good that it only worked on that one implementation that you had, and would've broken if you tried to use a different compiler. Judging by your mention of CodeWarrior, this all sounds like war stories from pre-standardization days (and of course it still took a while after ISO C++98 was published, for implementations to actually adopt it).
  - kps 8y ago
    > And it was never guaranteed that NULL (which is a macro) expands to just plain 0. True, but is was guaranteed that NULL expands to “an implementation-defined C++ null pointer constant” (C++98 §18.1), where a ‘null pointer constant’ is “an integral constant expression (5.19) rvalue of integer type that evaluates to zero" (C++98 §4.10). So while it didn't have to be just plain (literal) 0, it did have to be a compile-time constant integer 0, which is otherwise just as good unless you're doing macro magic. (This differed from C (ANSI era), in which a null pointer constant can alternatively have type (void*), and often does.) The fact that a pure declaration requires a literal single character ‘0’ (rather than 0) is just one sad example of C++'s ad-hoc irregular overloading of things to mean different things.
jandrese 8y ago
All of my old C++ code broke when namespaces were standardized. Most of it could be fixed with "using namespace std;" at the top, but it wouldn't compile out of the box.