4 ms·

This is 95% criticism about C++20 ranges (specifically the ranges v3 implementation), but spun as being about some more general trend. I think some of the criti

This is 95% criticism about C++20 ranges (specifically the ranges v3 implementation), but spun as being about some more general trend. I think some of the criticism of ranges is fair - compile times do matter and non-optimized performance can also matter. Stuff like `iota` being obscure is less convincing. It wasn't invented here and it is anyway something you learn once and then it's part of your vocabulary.

dundarious 5y ago
They mention the joke of adding boost being a fireable offense. Boost is a massive and very common dependency in less opinionated C++ codebases (i.e., a lot of corporate C++ codebases). There are plenty of other massive "all header, all template, all the time" C++ codebases. I think the trend for C++ libraries to be like this and to turn into major compilation time problems is already well established. If there has been any reversal of that trend, it's because of the observations and work of people like OP. As a side note, a major folk selling point for modules was that it might help with compile times, and a ton of work has gone into it in order to try to deliver. I haven't checked in on it in about a year, but my understanding is that it has largely failed on this front. Saying that there is a general trend/problem in C++ projects with very long compile times for even simple examples is, I think, an extremely well-grounded assertion (although ranges-v3 seems to be the new champion there).
- vinkelhake 5y ago
  Yeah, I agree that there are libs that have this problem, but it's not a new thing. Boost is a huge collection of libraries, with different properties and tradeoffs. It has been the case for two decades that a lot of the Boost libs are on the heavier side with regards to compile times. That's partly because Boost is an incubation chamber that pushes the limits. Perhaps an even bigger reason is that Boost libraries mostly err on the side of being generic, allowing users to wrap the lib around their data rather than the other way around. But really, there's nothing new here. When a developer brings in a library to their project there are always a bunch of dimensions to evaluate. Compile time is simply one that C++ developers have to evaluate, just like developers who rely on NPM have to ask themselves: what happens if $author goes nuts? FWIW, I think it's too early to declare failure on modules. The standard library hasn't been "modularized" yet, but the three major compilers all offer ways to import, rather than #include the standard lib. I just did an experiment the other day and switched my current hobby project to use import for my standard library dependencies and it nearly cut the build time in half. Very promising.
  - dundarious 5y ago
    I don't understand how it's not a general trend but it's also not a new thing. Saying it's not a general trend is the particular point I disagreed with. It's a general problem in the C++ world, especially with the "modern" stuff, and it's either as bad or worse than before. Some people say boost isn't "modern", because it has accumulated a lot of historical cruft to support buggy compilers (old versions and varied vendors). I don't think that's the most accurate interpretation. I think "Modern C++" became such a big thing after C++11 because the effort required to make and use boost style libraries dropped significantly -- no longer do you need your project to either depend on boost, or implement its own version of some NONCOPYABLE macro to disable copy/assignment(/move) operators, or what have you. I think saying "modern" means removing the hassle along the way to implementing boost, is to miss that the point is to be able implement things like boost -- implementing/using things like boost is what's "modern". The fact that an absolute ton of the new standard library features have an origin story in boost only further confirms this. One thing I forgot to mention when I distracted myself with modules, is that I totally agree with the author that the problem is also about debug build runtime performance, not just compile time. Interesting to hear about modules. I'm out of the C++ game but I'd be happy for it to be working well.
- int_19h 5y ago
  I will also note that, specifically in large "enterprisey" codebases, the benefit of all-encompassing libraries like Boost is that they only need to get approved once. If you ever had to jump through the hoops trying to get some third party code approved in an environment that is actively hostile to that, it's a godsend.

dundarious 5y ago

They mention the joke of adding boost being a fireable offense. Boost is a massive and very common dependency in less opinionated C++ codebases (i.e., a lot of corporate C++ codebases). There are plenty of other massive "all header, all template, all the time" C++ codebases. I think the trend for C++ libraries to be like this and to turn into major compilation time problems is already well established. If there has been any reversal of that trend, it's because of the observations and work of people like OP. As a side note, a major folk selling point for modules was that it might help with compile times, and a ton of work has gone into it in order to try to deliver. I haven't checked in on it in about a year, but my understanding is that it has largely failed on this front. Saying that there is a general trend/problem in C++ projects with very long compile times for even simple examples is, I think, an extremely well-grounded assertion (although ranges-v3 seems to be the new champion there).

vinkelhake 5y ago
Yeah, I agree that there are libs that have this problem, but it's not a new thing. Boost is a huge collection of libraries, with different properties and tradeoffs. It has been the case for two decades that a lot of the Boost libs are on the heavier side with regards to compile times. That's partly because Boost is an incubation chamber that pushes the limits. Perhaps an even bigger reason is that Boost libraries mostly err on the side of being generic, allowing users to wrap the lib around their data rather than the other way around. But really, there's nothing new here. When a developer brings in a library to their project there are always a bunch of dimensions to evaluate. Compile time is simply one that C++ developers have to evaluate, just like developers who rely on NPM have to ask themselves: what happens if $author goes nuts? FWIW, I think it's too early to declare failure on modules. The standard library hasn't been "modularized" yet, but the three major compilers all offer ways to import, rather than #include the standard lib. I just did an experiment the other day and switched my current hobby project to use import for my standard library dependencies and it nearly cut the build time in half. Very promising.
- dundarious 5y ago
  I don't understand how it's not a general trend but it's also not a new thing. Saying it's not a general trend is the particular point I disagreed with. It's a general problem in the C++ world, especially with the "modern" stuff, and it's either as bad or worse than before. Some people say boost isn't "modern", because it has accumulated a lot of historical cruft to support buggy compilers (old versions and varied vendors). I don't think that's the most accurate interpretation. I think "Modern C++" became such a big thing after C++11 because the effort required to make and use boost style libraries dropped significantly -- no longer do you need your project to either depend on boost, or implement its own version of some NONCOPYABLE macro to disable copy/assignment(/move) operators, or what have you. I think saying "modern" means removing the hassle along the way to implementing boost, is to miss that the point is to be able implement things like boost -- implementing/using things like boost is what's "modern". The fact that an absolute ton of the new standard library features have an origin story in boost only further confirms this. One thing I forgot to mention when I distracted myself with modules, is that I totally agree with the author that the problem is also about debug build runtime performance, not just compile time. Interesting to hear about modules. I'm out of the C++ game but I'd be happy for it to be working well.
int_19h 5y ago
I will also note that, specifically in large "enterprisey" codebases, the benefit of all-encompassing libraries like Boost is that they only need to get approved once. If you ever had to jump through the hoops trying to get some third party code approved in an environment that is actively hostile to that, it's a godsend.