4 ms·

I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation

I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. I think separate compilation and monomorphization are the biggest contributors, but I wouldn't be surprised if there was something I was forgetting. Somewhat related, there was some work in Rust about sharing monomorphized generics across crates, but it appears it was not a universal win at the time[0]. I'm not sure if anything has changed since that point, unfortunately, or if something similar could be applied to C++ somehow. [0]: https://github.com/rust-lang/rust/issues/47317#issuecomment-478894318 https://github.com/rust-lang/rust/issues/47317#issuecomment-...

josephg 3y ago
> I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation. The problem C++ has now is that the preprocessor operates on the raw text of a header file (which is a relic from C). This means the same header file can generate totally different source code each time its included in your program. C++ can't change that behaviour without breaking backwards compatibility. So headers get parsed over and over again "just in case" - wasting time producing excess code that just gets stripped back out again by the linker. The way C++ works doesn't make any sense now that memory is so much cheaper. Go, C#, java, rust, zig - basically every compiled language younger than C++ compiles faster than C++ because these languages don't contain C++'s design mistake. Rust doesn't share monomorphized generics across crates, but at least each crate is compiled as a single compilation unit.
- pjmlp 3y ago
  This was already the case with languages like Modula-2 and Object Pascal in the 1980's, C++ works that way because it was designed to be a drop-in in UNIX/C without additional requirements.

josephg 3y ago

> I'm not sure I'd call the design "bad". At the very least it's a product of the design constraints, and I'm not sure there's an obviously better implementation without sacrificing something else. It was a product of the design constraints in the 70s when memory was expensive, and compilers couldn't store a whole program in memory during compilation. The problem C++ has now is that the preprocessor operates on the raw text of a header file (which is a relic from C). This means the same header file can generate totally different source code each time its included in your program. C++ can't change that behaviour without breaking backwards compatibility. So headers get parsed over and over again "just in case" - wasting time producing excess code that just gets stripped back out again by the linker. The way C++ works doesn't make any sense now that memory is so much cheaper. Go, C#, java, rust, zig - basically every compiled language younger than C++ compiles faster than C++ because these languages don't contain C++'s design mistake. Rust doesn't share monomorphized generics across crates, but at least each crate is compiled as a single compilation unit.

pjmlp 3y ago
This was already the case with languages like Modula-2 and Object Pascal in the 1980's, C++ works that way because it was designed to be a drop-in in UNIX/C without additional requirements.