6 ms·

This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern feature

This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for any developers. For example: >It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change. This is simply a bogus statement with respect to what at least 90% of c++ developers do on a daily basis. I have benchmarked unique_ptr, auto, brace initialization, lambdas, range-based-for and other modern idioms and found them all to be at least as fast, and often faster, than their older counterparts. Now, if I were to instead go off and write template-heavy code using new features, that would be different. But in reality, the vast majority of c++ developers -- I'd wager at least 95% -- are not writing variadic templates on a daily basis (nor should they be). The memory safety and many benefits from unique_ptr [0] is one of many modern tools that is a non-brainer to use in nearly all contexts. No, not nearly all contexts, allow me to rephrase: all contexts. It just is, and if you compare its use to manual new/delete code, the benefits are solid and faster. The author further claims that modern C++ is less maintainable and more complex. The absolute opposite is true in nearly all cases. Using unique_ptr again as an example, it leads to less code, less complex code, more clear code, and better maintainability and code readability. Uniform brace initialization is another example that prevents many common older problems in the language. FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political. I think the title of this article is highly misleading, and the contents are not relevant. Overall, this article is just bad advice for most of us. [0] https://news.ycombinator.com/item?id=11699954 https://news.ycombinator.com/item?id=11699954

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.
gpderetta 10y ago
"Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. " FWIW, I have been on the industry only 3 years so far, but I also see modern C++ and boost everywhere. I'm aware of the obvious selection bias, but then again it also applies to the author: if a firm has to call an external consultant to make sense of their codebase, it wasn't probably very good to start with.
physguy1123 10y ago
> FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political. Just an anecdote, but I also work at a successful HFT as well modern C++ is almost everywhere, without any performance hits and much cleaner code. Often it's easier to write fast code with it.
nmeofthestate 10y ago
(re 10 minute compile times) > This is simply a bogus statement I work on a C++ project and believe me, 10 minute compile times would be great :)
- hellofunk 10y ago
  The bogus part is 10 minutes vs a few seconds just because you change to the latest standard.
- matthewaveryusa 10y ago
  have you tried ccache? the 5x to 10x improvement isn't a bogus statement in my experience
  - pjc50 10y ago
    ccache doesn't help as soon as you change a popular header file. distcc helps quite a bit, but there was a project I worked on for years where by the end the compile time was 15 minutes after you'd distributed it across 20 machines.
  - plorkyeran 10y ago
    ccache eliminates spurious rebuilds, but doesn't make compilation of things which actually need to be recompiled any faster. It's basically just a workaround for that Make only uses file mtimes and not the contents to decide what needs to be built.
    - matthewaveryusa 10y ago
      In theory, agreed. In practice I see a lot of re-compilation in large projects.
fish2000 10y ago
“A Variadic Template A Day Keeps The Job Security In Play”
- gpderetta 10y ago
  You should see the code that variadic templates replace.
  - hellofunk 10y ago
    Say more! I'd like to know what you mean.
    - gpderetta 10y ago
      Before variadic templates you couldn't define a function template taking an arbitrary number of arguments; what you could do is define N overloads up to a finite large N. This quickly becomes tedious and hard to maintain, so you either write an external generator script, or 'creatively' use the preprocessor. These solutions were also not much easier to maintain and of course would kill compilation times. The worst part is that often these were forwarding functions, that is, they didn't do anything directly with their parameters, but simply forwarded them to some other function (this happen surprisingly often in highly generic code). To do forwarding correctly, you have to handle const and non const reference arguments properly, which means that N overloads are not enough and you need N*2^N (someone please check my math) overloads. As you can imagine, this was impractical for N > 3. Variadic templates plus perfect forwarding via magic references make easy, practical and possible what was impractical before. edit: spelling

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.

gpderetta 10y ago

"Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. " FWIW, I have been on the industry only 3 years so far, but I also see modern C++ and boost everywhere. I'm aware of the obvious selection bias, but then again it also applies to the author: if a firm has to call an external consultant to make sense of their codebase, it wasn't probably very good to start with.

physguy1123 10y ago

> FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political. Just an anecdote, but I also work at a successful HFT as well modern C++ is almost everywhere, without any performance hits and much cleaner code. Often it's easier to write fast code with it.

nmeofthestate 10y ago

(re 10 minute compile times) > This is simply a bogus statement I work on a C++ project and believe me, 10 minute compile times would be great :)

hellofunk 10y ago
The bogus part is 10 minutes vs a few seconds just because you change to the latest standard.
matthewaveryusa 10y ago
have you tried ccache? the 5x to 10x improvement isn't a bogus statement in my experience
- pjc50 10y ago
  ccache doesn't help as soon as you change a popular header file. distcc helps quite a bit, but there was a project I worked on for years where by the end the compile time was 15 minutes after you'd distributed it across 20 machines.
- plorkyeran 10y ago
  ccache eliminates spurious rebuilds, but doesn't make compilation of things which actually need to be recompiled any faster. It's basically just a workaround for that Make only uses file mtimes and not the contents to decide what needs to be built.
  - matthewaveryusa 10y ago
    In theory, agreed. In practice I see a lot of re-compilation in large projects.

fish2000 10y ago

“A Variadic Template A Day Keeps The Job Security In Play”

gpderetta 10y ago
You should see the code that variadic templates replace.
- hellofunk 10y ago
  Say more! I'd like to know what you mean.
  - gpderetta 10y ago
    Before variadic templates you couldn't define a function template taking an arbitrary number of arguments; what you could do is define N overloads up to a finite large N. This quickly becomes tedious and hard to maintain, so you either write an external generator script, or 'creatively' use the preprocessor. These solutions were also not much easier to maintain and of course would kill compilation times. The worst part is that often these were forwarding functions, that is, they didn't do anything directly with their parameters, but simply forwarded them to some other function (this happen surprisingly often in highly generic code). To do forwarding correctly, you have to handle const and non const reference arguments properly, which means that N overloads are not enough and you need N*2^N (someone please check my math) overloads. As you can imagine, this was impractical for N > 3. Variadic templates plus perfect forwarding via magic references make easy, practical and possible what was impractical before. edit: spelling