4 ms·

I know it's trollish, but as person using C++ I have to do it: Writing software using C++ in 2016 is an anti-pattern.

by dpc_pw 10y ago

geezerjay 10y ago
How so?
- pjc50 10y ago
  Starting a C++ project in 2016 is probably an antipattern, yes. For those rare days when someone gets to start a piece of software in a green field. And I say this as someone with more than 20 years of C++ experience. It's just too bug-prone, even if you try to enforce C++14 style everywhere with code reviews. There's always an area where that style doesn't fit, usually around the critically important library or API which made you choose C++ in the first place. It takes too long to build. It's hard to modularise away the build speed and interdependency issues. It's far too hard to ensure security, if your software ends up on an attack surface.
  - geezerjay 10y ago
    I'm not sure you're being serious. Giving you the benefit of the doubt, what real-world programming language would you propose as an improvement regarding the aspects you've mentioned?
  - Ace17 10y ago
    15 years C++ programmer here. First, all your arguments (except for the build time) also apply to C. So I'm gonna make the assumption that today, you wouldn't start a greenfield C project either. Then, what would you use, say, to develop: * a commercial video game engine? (of course, you can't afford your engine to run slower than the engine from your competitor). * bare-metal software with hard memory constraints? (for example, the firmware of a hardware virtual analog synthesizer). * a real-time video encoder, like x264? (where more speed meaning more video quality in this context) * HFT software? (where more speed means more money) Now for the build times. C++ compilation time definitely is a serious issue, and I'd kill for a faster C++ compilation process. But the interdependency issues you mention are not created by C++, nor are they even enabled by C++. It's true that in C++, such issues will have the side-effect of slowing down your build (mostly by causing lots of recompilations when you only modify one file). Duck-typed languages might give the (wrong) feeling that there are less dependencies in your project. But it's just that lots of them are implicit, and that the consistency between the caller and the callee only being checked at run time, it doesn't slow down the "build". You still might run into things like strong coupling, cyclic dependencies, fragile base class, violations of the dependency inversion principle, classes with huge fan-out.
Ace17 10y ago
Writing software using C++03 in 2016 is an anti-pattern. To quote Bjarne Stroustrup himself, "C++11 feels like a different language".

I know it's trollish, but as person using C++ I have to do it: Writing software using C++ in 2016 is an anti-pattern.

by dpc_pw 10y ago

I know it's trollish, but as person using C++ I have to do it: Writing software using C++ in 2016 is an anti-pattern.

geezerjay 10y ago

How so?

pjc50 10y ago
Starting a C++ project in 2016 is probably an antipattern, yes. For those rare days when someone gets to start a piece of software in a green field. And I say this as someone with more than 20 years of C++ experience. It's just too bug-prone, even if you try to enforce C++14 style everywhere with code reviews. There's always an area where that style doesn't fit, usually around the critically important library or API which made you choose C++ in the first place. It takes too long to build. It's hard to modularise away the build speed and interdependency issues. It's far too hard to ensure security, if your software ends up on an attack surface.
- geezerjay 10y ago
  I'm not sure you're being serious. Giving you the benefit of the doubt, what real-world programming language would you propose as an improvement regarding the aspects you've mentioned?
- Ace17 10y ago
  15 years C++ programmer here. First, all your arguments (except for the build time) also apply to C. So I'm gonna make the assumption that today, you wouldn't start a greenfield C project either. Then, what would you use, say, to develop: * a commercial video game engine? (of course, you can't afford your engine to run slower than the engine from your competitor). * bare-metal software with hard memory constraints? (for example, the firmware of a hardware virtual analog synthesizer). * a real-time video encoder, like x264? (where more speed meaning more video quality in this context) * HFT software? (where more speed means more money) Now for the build times. C++ compilation time definitely is a serious issue, and I'd kill for a faster C++ compilation process. But the interdependency issues you mention are not created by C++, nor are they even enabled by C++. It's true that in C++, such issues will have the side-effect of slowing down your build (mostly by causing lots of recompilations when you only modify one file). Duck-typed languages might give the (wrong) feeling that there are less dependencies in your project. But it's just that lots of them are implicit, and that the consistency between the caller and the callee only being checked at run time, it doesn't slow down the "build". You still might run into things like strong coupling, cyclic dependencies, fragile base class, violations of the dependency inversion principle, classes with huge fan-out.

Ace17 10y ago

Writing software using C++03 in 2016 is an anti-pattern. To quote Bjarne Stroustrup himself, "C++11 feels like a different language".