3 ms·

No. C++ is slow to compile due to some historical decisions like preprocessor. But the C++ standard committee has come to rely on optimizing compilers with po

No. C++ is slow to compile due to some historical decisions like preprocessor. But the C++ standard committee has come to rely on optimizing compilers with powerful inliners and optimizers, to implement new "zero cost" [sic] abstractions as convoluted template libraries with lot of corner cases (neglecting incomprehensible error messages and debug build performance as well). Efficiently compiling C++ effectively __requires__ a top notch optimizer because of the disconnect between standards committee and implementers. Moreover, relying on optimizers often results in non obvious performance traps. The stupidity of standards committee and their sheer insistence on nothing but being able to sell more books every years is why even modern C++ is such a horrible development experience.

ncmncm 6y ago
This description is absolutely at variance with the reality of C++ Standard activity. Compiler and Standard Library implementers are intimately involved in all phases of standardization. Book sales have much less effect than authors would like; they would prefer many fewer changes. Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. C++20 is nicer than '17, which is nicer than '14, which is nicer than '11, which is much nicer than '03, which is a little nicer than '98. '23 will be nicer than all of them.
- higerordermap 6y ago
  Eh? I don't understand which kind of involvement. I occassionally read C++ proposals, and also read blogs from some very good C++ programmers. The "everything implemented as library" pattern so pervasive in new C++ releases is not doing any good to the language. All those are half-baked implementation of what exists as a simple orthogonal language feature in languages like OCaml. The "implement as library" sentiment has gone too far that it hurts, among other things: * Debug build performance * Compilation times (a big thing) * Quality of error messages * Reliance on not-so-reliable optimizations, often causing performance regressions (there are many instances of this happening). Even if clang / gcc developers are involved, probably they don't bother about 1000::template shittery because their compilers have already got comparable quality inliners, and it is hard for a competition to surface here. Or they might bother but can't be sufficiently involved into the C++ standard committee crowd. > Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. And don't tell me my knowledge of last standard is obsolete and I have to read the new shiny c++ book to learn Modern C++. Another consequence is the scarcity of freely available resources accessible to students, due to rapid change.
  - ncmncm 6y ago
    You may invent whichever activities suit your imagination, but I can state with absolute authority of decades' experience that they are utterly divorced from any objective reality. Most people learning the newer features of C++ do not turn first to books, but rely on cppreference.com, blog posts, and on conference videos easily found on youtube. The best way to learn the new features is to use them.
- guenthert 6y ago
  Beauty in the eye of the beholder. Clearly C++20 has more features than C++17, which had more features that C++14, etc., but nicer? There are some features which are nice, but the whole set? And some of those features solve just problems one doesn't have outside of C++ and other problems remain. I think C++ is the Algol68 of our days. It won't be improved upon, but (hopefully soon) replaced.
  - ncmncm 6y ago
    I can only report my own experience, but programming with concepts is definitely better than without, with generic lambdas better than without, with template variadics better than without, with pass-by-move better than without. It would be lovely to have a more modern language with C++'s capabilities, but no such language is even approaching the horizon. Rust aspires to such a role, but more people pick up C++ each week than have ever coded one line of Rust. Adoption, judging from conference attendance and youtube viewership, is today growing faster than ever. You may imagine C++ stagnating, but only by abandoning reality. Essentially all of the highest-paid development for the most demanding applications is today done in C++. For reasons. There are only two kinds of language: those people complain about, and those no one uses. C++ is complained about more than any except Java or Javascript.
Gibbon1 6y ago
You don't get it, the language is terrible from a compilation point. I would say designed but that would be an insult to people that actually did/do design languages. You can't actually fix it, you can only make it worse. Simple point: Adding optimizations doesn't speed C++ compilers up faster than having do those optimizations slows them down. Solution, stop using C++ for anything. The most hopeful thing in the last 5 years is the move to remove C++ from new languages tool chains. Good because C++ is hopelessly broken.
- higerordermap 6y ago
  > Simple point: Adding optimizations doesn't speed C++ compilers up faster than having do those optimizations slows them down. Well that's an obvious point. > Solution, stop using C++ for anything. We can't, realistically. I know rust is great in many aspects. I know lot of software in C++ can be written better even in an AOT'd GC language with equal or better performance, because of so many C++ performance pitfalls that appear at scale. But we can't throw away all the code already written. There is lot of talent pool for C++. And the supposedly better languages have non existent talent pool. (Go doesn't count, such a boilerplate language hampers any readability at scale).
  - ncmncm 6y ago
    I wonder what these "performance pitfalls at scale" are, that other languages succeed in avoiding. Normally such an expression would refer to abstraction overhead, but this is where C++ excels. Cache nonlinearities, with pipeline stalls and branch prediction failures, affect all languages. Control of memory footprint is essential to avoiding those, but C++ exceeds others there, too.

ncmncm 6y ago

This description is absolutely at variance with the reality of C++ Standard activity. Compiler and Standard Library implementers are intimately involved in all phases of standardization. Book sales have much less effect than authors would like; they would prefer many fewer changes. Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. C++20 is nicer than '17, which is nicer than '14, which is nicer than '11, which is much nicer than '03, which is a little nicer than '98. '23 will be nicer than all of them.

higerordermap 6y ago
Eh? I don't understand which kind of involvement. I occassionally read C++ proposals, and also read blogs from some very good C++ programmers. The "everything implemented as library" pattern so pervasive in new C++ releases is not doing any good to the language. All those are half-baked implementation of what exists as a simple orthogonal language feature in languages like OCaml. The "implement as library" sentiment has gone too far that it hurts, among other things: * Debug build performance * Compilation times (a big thing) * Quality of error messages * Reliance on not-so-reliable optimizations, often causing performance regressions (there are many instances of this happening). Even if clang / gcc developers are involved, probably they don't bother about 1000::template shittery because their compilers have already got comparable quality inliners, and it is hard for a competition to surface here. Or they might bother but can't be sufficiently involved into the C++ standard committee crowd. > Furthermore, C++ coding experience improves markedly with each new Standard, released on a 3-year cadence. And don't tell me my knowledge of last standard is obsolete and I have to read the new shiny c++ book to learn Modern C++. Another consequence is the scarcity of freely available resources accessible to students, due to rapid change.
- ncmncm 6y ago
  You may invent whichever activities suit your imagination, but I can state with absolute authority of decades' experience that they are utterly divorced from any objective reality. Most people learning the newer features of C++ do not turn first to books, but rely on cppreference.com, blog posts, and on conference videos easily found on youtube. The best way to learn the new features is to use them.
guenthert 6y ago
Beauty in the eye of the beholder. Clearly C++20 has more features than C++17, which had more features that C++14, etc., but nicer? There are some features which are nice, but the whole set? And some of those features solve just problems one doesn't have outside of C++ and other problems remain. I think C++ is the Algol68 of our days. It won't be improved upon, but (hopefully soon) replaced.
- ncmncm 6y ago
  I can only report my own experience, but programming with concepts is definitely better than without, with generic lambdas better than without, with template variadics better than without, with pass-by-move better than without. It would be lovely to have a more modern language with C++'s capabilities, but no such language is even approaching the horizon. Rust aspires to such a role, but more people pick up C++ each week than have ever coded one line of Rust. Adoption, judging from conference attendance and youtube viewership, is today growing faster than ever. You may imagine C++ stagnating, but only by abandoning reality. Essentially all of the highest-paid development for the most demanding applications is today done in C++. For reasons. There are only two kinds of language: those people complain about, and those no one uses. C++ is complained about more than any except Java or Javascript.

Gibbon1 6y ago

You don't get it, the language is terrible from a compilation point. I would say designed but that would be an insult to people that actually did/do design languages. You can't actually fix it, you can only make it worse. Simple point: Adding optimizations doesn't speed C++ compilers up faster than having do those optimizations slows them down. Solution, stop using C++ for anything. The most hopeful thing in the last 5 years is the move to remove C++ from new languages tool chains. Good because C++ is hopelessly broken.

higerordermap 6y ago
> Simple point: Adding optimizations doesn't speed C++ compilers up faster than having do those optimizations slows them down. Well that's an obvious point. > Solution, stop using C++ for anything. We can't, realistically. I know rust is great in many aspects. I know lot of software in C++ can be written better even in an AOT'd GC language with equal or better performance, because of so many C++ performance pitfalls that appear at scale. But we can't throw away all the code already written. There is lot of talent pool for C++. And the supposedly better languages have non existent talent pool. (Go doesn't count, such a boilerplate language hampers any readability at scale).
- ncmncm 6y ago
  I wonder what these "performance pitfalls at scale" are, that other languages succeed in avoiding. Normally such an expression would refer to abstraction overhead, but this is where C++ excels. Cache nonlinearities, with pipeline stalls and branch prediction failures, affect all languages. Control of memory footprint is essential to avoiding those, but C++ exceeds others there, too.