4 ms·

> C++ has a rather odd culture... it's very a very fundamentalist/extremist one, all providing the optimal way to do things with no / little extra runtime overh

by NL807 5y ago

> C++ has a rather odd culture... it's very a very fundamentalist/extremist one, all providing the optimal way to do things with no / little extra runtime overhead, but with no regard at all to compile times, readability, etc. It think this is attributed to fundamental rule of not breaking legacy language features. That is the number one rule (much like how Linus is iron fisted about not breaking user space in the Linux environment). However, there is a lot of wiggle room in the way binaries are generated, so compiler authors can get really creative with their optimisation efforts.

inetknght 5y ago
> It think this is attributed to fundamental rule of not breaking legacy language features. That is the number one rule No. The number one rule in C++ is "don't pay for what you don't use".
- jsheard 5y ago
  To be more specific it's "don't pay in runtime cost for what you don't use". As the OP says that courtesy isn't extended to compile times - simply enabling C++17/20 can balloon your compile times even if you don't touch a single new feature, because the standard headers get more and more bloated with each new version. https://build-bench.com/b/FW3EPgB1t0fmpIr1TB_vJbbb0Vw https://build-bench.com/b/FW3EPgB1t0fmpIr1TB_vJbbb0Vw Which is exacerbated even more by the leaky #include system, where you can easily end up pulling enormous standard headers into translation units that don't even reference them directly. The only reprieve is to ban most of the standard library from your project and write your own leaner version from scratch, as most big C++ projects end up doing.
  - riskneutral 5y ago
    There are ways to speed up compilation. It can be done in parallel, and you can get a lot of cores into a developer desktop these days. Plus you can get unlimited amounts of distributed cores in the cloud. Compilation can also be sped up with pre-compiled headers, which will soon be replaced with C++20 modules which will help compilation improve in the future as compilers improve their support for modules. With incremental compilation, you do not need recompile the whole project after every change. Linking in large statically linked binaries is a big bottleneck, but incremental linking is possible in some cases. You can also break your project into multiple shared libraries (DLLs) , and link dynamically at run-time for debugging. It can then be re-built with static linking for a release build. Continuous Integration systems can also help hide the latency of compilation from developers by continuously running build and test processes in the background on a cluster.
    - deleted 5y ago
      [deleted]
    - lttlrck 5y ago
      ccache can considerably cut down compile times. Simple to install and minimal config, no change to tooling or workflow... https://ccache.dev/ https://ccache.dev/
    - Agingcoder 5y ago
      It's possible, and I know first hand it is. It requires quite a bit of work though. It might be easier to just have quick compile times though!
    - fivea 5y ago
      > There are ways to speed up compilation. It can be done in parallel, and you can get a lot of cores into a developer desktop these days. I'd start with the very basics, such as using forward declarations, encapsulation, and the pimpl idiom to not drag unnecessary #includes into your translation units. Also, the compilation bottleneck sometimes lies in IO, thus moving your build folder to a RAM drive can speed up things significantly with zero effort.
- NL807 5y ago
  I'd argue not breaking old code has precedence over zero cost abstraction.
  - bregma 5y ago
    It's not a contest. They're both fundamental requirements. Mom doesn't like one of them best.
    - gpderetta 5y ago
      But indeed, when the option is between maintaining backward compatibility or further reducing overhead, the C++ committee usually choses the former, at least on the library side. See for example the less then ideal unique_ptr constructor or the invalidation guarantees of the unordered containers.
- sharikous 5y ago
  Number two rule is staying similar to C and not breaking legacy features. That's the fundamental difference with Rust (although you can argue that when languages get bigger you are always bound to become a slave of the language)
DSMan195276 5y ago
> It think this is attributed to fundamental rule of not breaking legacy language features. Is this really all that unique to C++? Or are you saying that it's just particularly painful for C++ due to where it started from?
- bregma 5y ago
  It's not that unique to C++. It's a property of useful things that have been successful for a long time.
- NL807 5y ago
  Not unique to C++, but strongly enforced. Work groups that standardise new C++ features is very reluctant to make any breaking changes.

by NL807 5y ago

inetknght 5y ago

> It think this is attributed to fundamental rule of not breaking legacy language features. That is the number one rule No. The number one rule in C++ is "don't pay for what you don't use".

jsheard 5y ago
To be more specific it's "don't pay in runtime cost for what you don't use". As the OP says that courtesy isn't extended to compile times - simply enabling C++17/20 can balloon your compile times even if you don't touch a single new feature, because the standard headers get more and more bloated with each new version. https://build-bench.com/b/FW3EPgB1t0fmpIr1TB_vJbbb0Vw https://build-bench.com/b/FW3EPgB1t0fmpIr1TB_vJbbb0Vw Which is exacerbated even more by the leaky #include system, where you can easily end up pulling enormous standard headers into translation units that don't even reference them directly. The only reprieve is to ban most of the standard library from your project and write your own leaner version from scratch, as most big C++ projects end up doing.
- riskneutral 5y ago
  There are ways to speed up compilation. It can be done in parallel, and you can get a lot of cores into a developer desktop these days. Plus you can get unlimited amounts of distributed cores in the cloud. Compilation can also be sped up with pre-compiled headers, which will soon be replaced with C++20 modules which will help compilation improve in the future as compilers improve their support for modules. With incremental compilation, you do not need recompile the whole project after every change. Linking in large statically linked binaries is a big bottleneck, but incremental linking is possible in some cases. You can also break your project into multiple shared libraries (DLLs) , and link dynamically at run-time for debugging. It can then be re-built with static linking for a release build. Continuous Integration systems can also help hide the latency of compilation from developers by continuously running build and test processes in the background on a cluster.
  - deleted 5y ago
    [deleted]
  - lttlrck 5y ago
    ccache can considerably cut down compile times. Simple to install and minimal config, no change to tooling or workflow... https://ccache.dev/ https://ccache.dev/
  - Agingcoder 5y ago
    It's possible, and I know first hand it is. It requires quite a bit of work though. It might be easier to just have quick compile times though!
  - fivea 5y ago
    > There are ways to speed up compilation. It can be done in parallel, and you can get a lot of cores into a developer desktop these days. I'd start with the very basics, such as using forward declarations, encapsulation, and the pimpl idiom to not drag unnecessary #includes into your translation units. Also, the compilation bottleneck sometimes lies in IO, thus moving your build folder to a RAM drive can speed up things significantly with zero effort.
NL807 5y ago
I'd argue not breaking old code has precedence over zero cost abstraction.
- bregma 5y ago
  It's not a contest. They're both fundamental requirements. Mom doesn't like one of them best.
  - gpderetta 5y ago
    But indeed, when the option is between maintaining backward compatibility or further reducing overhead, the C++ committee usually choses the former, at least on the library side. See for example the less then ideal unique_ptr constructor or the invalidation guarantees of the unordered containers.
sharikous 5y ago
Number two rule is staying similar to C and not breaking legacy features. That's the fundamental difference with Rust (although you can argue that when languages get bigger you are always bound to become a slave of the language)

DSMan195276 5y ago

> It think this is attributed to fundamental rule of not breaking legacy language features. Is this really all that unique to C++? Or are you saying that it's just particularly painful for C++ due to where it started from?

bregma 5y ago
It's not that unique to C++. It's a property of useful things that have been successful for a long time.
NL807 5y ago
Not unique to C++, but strongly enforced. Work groups that standardise new C++ features is very reluctant to make any breaking changes.