
C++ Antipatterns - ingve
https://accu.org/index.php/journals/2271
======
dpc_pw
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
How so?

~~~
pjc50
_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.

~~~
Ace17
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.

------
pjc50
Checking istream: every piece of example code for beginners that I've ever
seen fails to do this. Including, if I remember rightly, Strostrup.

But then most people realise early on that istream makes a very bad parser for
real data because there's no sensible way of doing error recovery with it.

------
belovedeagle
The author named the post wrong since he provided the correct patterns which
were way more informative :)

~~~
geezerjay
The main issue with the post is that it actually doesn't cover anti-patterns
at all. It shows common mistakes, and presents the correct usage of the
language accompanied by best practices.

