5 ms·

I got the feeling that the author's beef with Modern C++ is the same as for any C++ that is template heavy. And to me it is not a new or unique experience (i.e.

by daemin 10y ago

I got the feeling that the author's beef with Modern C++ is the same as for any C++ that is template heavy. And to me it is not a new or unique experience (i.e. not limited to Modern C++) to have builds that take 45 minutes to build everything. It can happen in older code and in newer code.

adrianN 10y ago
Yes, templates make the compiler work harder (sometimes at least), but badly modularized code with "big ball of mud" dependency structure also makes the compiler work a lot. You don't need fancy features to do that.
- daemin 10y ago
  In my experience both have been true. That's why you get 10+ minute link times in some projects, so even if you use Incredibuild to compile, it still takes ages to link.
- adrianratnapala 10y ago
  "Big ball of mud" dependency structures are common because the most pragmatic quick-fix for so many compile errors it to just whack in a new #include. C++ is worse than most languages in this way, because private members are defined in public headers. This forces you add #includes to the headers. Thus the #include graph is much denser than the true dependencies in your program. There's tricks for getting around this, but they aren't always practical; and they go against the grain of the "every class has its own .cpp and .h file" rule, which lots of people want to insist on.
  - leni536 10y ago
    >There's tricks You mean PIMPL?
    - adrianratnapala 10y ago
      Yes, I think so, though I was never truly clear on what PIMPL was supposed to mean. I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. There are some other tricks you can do too, such as using pointers-to-incomplete types. When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.
      - hellofunk 10y ago
        PIMPL means "pointer to implementation" and the reason you and your colleagues are having difficulty with it is because you don't understand it, and therefore should not be using it, or, investing the time to understand it before trying to use it. >every class has its own .cpp and .h file Wrong. There are so many high-quality and widely-used libraries that are "header only". >When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all. It is possible to write sloppy code in any language, and also to receive low-quality contributions from anyone else to your code. This is not unique to C++. That's why it is important that everyone in a team be on the same page about how code is organized. >I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. This is not the PIMPL idiom, though it is halfway right.
    - aspiringuser 10y ago
      PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.
      - hellofunk 10y ago
        With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.

by daemin 10y ago

adrianN 10y ago

Yes, templates make the compiler work harder (sometimes at least), but badly modularized code with "big ball of mud" dependency structure also makes the compiler work a lot. You don't need fancy features to do that.

daemin 10y ago
In my experience both have been true. That's why you get 10+ minute link times in some projects, so even if you use Incredibuild to compile, it still takes ages to link.
adrianratnapala 10y ago
"Big ball of mud" dependency structures are common because the most pragmatic quick-fix for so many compile errors it to just whack in a new #include. C++ is worse than most languages in this way, because private members are defined in public headers. This forces you add #includes to the headers. Thus the #include graph is much denser than the true dependencies in your program. There's tricks for getting around this, but they aren't always practical; and they go against the grain of the "every class has its own .cpp and .h file" rule, which lots of people want to insist on.
- leni536 10y ago
  >There's tricks You mean PIMPL?
  - adrianratnapala 10y ago
    Yes, I think so, though I was never truly clear on what PIMPL was supposed to mean. I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. There are some other tricks you can do too, such as using pointers-to-incomplete types. When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.
    - hellofunk 10y ago
      PIMPL means "pointer to implementation" and the reason you and your colleagues are having difficulty with it is because you don't understand it, and therefore should not be using it, or, investing the time to understand it before trying to use it. >every class has its own .cpp and .h file Wrong. There are so many high-quality and widely-used libraries that are "header only". >When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all. It is possible to write sloppy code in any language, and also to receive low-quality contributions from anyone else to your code. This is not unique to C++. That's why it is important that everyone in a team be on the same page about how code is organized. >I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. This is not the PIMPL idiom, though it is halfway right.
  - aspiringuser 10y ago
    PIMPL pattern is great for reducing compilation time and creating stable user-facing APIs but it has a runtime cost. The "implementation" part is usually heap allocated and calling its methods have extra overhead of crossing the pointer to implementation barrier.
    - hellofunk 10y ago
      With the use of link-time optimization, most of the overhead of using pimpl idiom is removed. Both the outter wrapper functions as well as the implementation functions can be inlined, making the function calls effectively like a normal class implemented inside a header.