4 ms·
I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process. Instead of letting compiler implementers decide
by maxloh 5mo ago
I think the problem is that C++ is a poorly designed language with a fundamentally flawed development process.
Instead of letting compiler implementers decide which features to add and how to implement them, C++ employs a standards-first, top-down approach. Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to catch up.
Some features were standardized back in 2023, yet not a single implementation supports them in 2026.
https://en.cppreference.com/cpp/compiler_support https://en.cppreference.com/cpp/compiler_support
https://cppstat.dev/ https://cppstat.dev/
- weinzierl 5mo agoThis is so true and it's a danger for other ecosystems too. Once the big corporations throw their weight in (be it in a committee or only informally) they make their use cases dominant regardless how niche they might be for the rest of the world. For example in Rust there is one big entity that currently pours a lot of energy into improving C++ interop. Now, this is not exactly a niche topic, but especially in a world where AI makes many rewrites possible that we wouldn't have daunted to think about a couple of years before, we shouldn't waste too much effort to save legacy companies enormous codebases at the detriment of our preferred language.
- remix2000 5mo agoRust is impl-first bottom-up and it's stuck with a single implementation and GCC for Rust is still in the works, meanwhile C++26 reflection is already in GCC trunk.
- bitwize 5mo agoRust is also the systems programming language of the future. They're pretty much doing everything right.
- uecker 5mo agoWhat IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get anything done, an ecosystem susceptible to supply-chain attacks, no ISO standard.
- nicoty 5mo agoOut of curiosity, what do you think is wrong with monomorphization-based polymorphism? The other alternatives I'm aware of are 1. type-erasure via v-table based dynamic dispatch (which Rust also has in the form of the `dyn` keyword), which has performance and memory-allocation overhead and 2. macros, which Rust also has and, if used for polymorphism, would essentially be like compile-time monomorphization, but clunkier. Maybe I'm missing something though and there are other alternatives done differently in other languages?
- uecker 5mo agoThe correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with monomorphization is that it leads to exponential expansion, which later passes of the compiler can not unify again (at least this is much harder than not expanding in the first place). It should also fundamentally limit what you can do, because expansion has to stop at some point, but I haven't thought about this too much. I also think that where you want monomophization, macro seem fine. I do not think this necessarily has to be clunky, but this is just a guess.
- tialaramex 5mo ago
- saalweachter 5mo ago> Features are often defined by committee members who may not use modern C++ in their daily workflows, leaving it entirely up to the individual implementations to catch up. Eh, all of the committee members I've known are obsessed with modern C++, and "can this feature be implemented?" is definitely a blocker; numerous features got kicked down the road from C++0x to later versions because compilers weren't ready for them.
- einpoklum 5mo agoC++ is a language with perfect 30-year backwards compatibility, and which mostly-maintains compatibility with another language it forked from (C), after 40 years of diverging development. Rust is a language which isn't backwards-compatible, and certainly not compatible with source code in other languages. Now, sure, Rust has its advantages, but - how can you fault C++ in the context of compatibility?
- lepicz 5mo agothis compatibility sucks sometimes. for example you want to add nice feature to c++ with nice syntax, but there is a similar syntax somewhere in C that nobody uses, but you have to support it. you end up with nice feature with horrible syntax.
- skrebbel 5mo ago> committee members who may not use modern C++ in their daily workflows Are you sure about this one? I don’t know exactly who’s in the committee these days but last I checked they were all hardcore C++ programmers with decades of experience from the trenches.
- tardedmeme 5mo agoI don't think that's true? Nothing gets in the standard without substantial actual experience on at least an experimental compiler branch first. It's just not always your compiler.
- mrec 5mo ago`export template` was included in the C++98 standard without any experience, experimental or otherwise. The first implementation was achieved by EDG after enormous pain in the early 2000s, and their advice for any others attempting it was "don't". I'm not aware of anything else quite that egregious, though. https://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n1426.pdf https://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n14...
- tardedmeme 5mo agoThere were compilers that used the template export implementation, but not with that exact syntax. I think that's how cfront did templates.
- spacechild1 5mo agoThe one big and tragic exception being modules...
- pjmlp 5mo agoC++11 GC, modules, contracts, linalg are good examples of not having a substantial actual experience before ratification. Now, I rather have them than not, but it is still clunky.