
Dark Corners and Pitfalls of C++ - SimbirSoft
https://www.codeproject.com/Articles/5164537/Dark-corners-and-pitfalls-of-Cplusplus
======
jupp0r
A lot of things pointed out in the article shouldn't prevent anybody from
starting a project in modern C++. First of all, usage of raw arrays is
discouraged, if you use std::array or std::vector, there are way less ways to
shoot yourself. Same goes for manually managing memory, you shouldn't ever
have to call delete on your own nowadays. Most other problems mentioned in the
article are ABI compatibility and dynamic library loading problems that are
super specific to Windows and that very few people should ever have to deal
with. This is going to painful no matter what language you are using. Win32
API is no fun, hardly C++s fault.

~~~
serial_dev
I see these kinds of comments very often ("Ackchyually, feature X of C++ has
been discouraged for at least Y years now and if you still use it, you are
doomed").

I used to learn C++ at the university (~5 years ago) and have read multiple
books on that, however, I would have no idea how to start using the language
again and how to figure out which patterns are OK and which ones are
discouraged and what should I use instead. All "modern C++" books I found are
10+ years old.

There seem to be so many opinions out there on forums, but I don't see a
comprehensive, community-approved place (book or website) where I can learn
and understand the differences between the many ways of doing the same thing.

~~~
AlexeyBrin
> I don't see a comprehensive, community-approved place (book or website)
> where I can learn and understand the differences between the many ways of
> doing the same thing

Check _C++ Core Guidelines_
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)
which is a community approved collection of best practices for modern C++.

------
einpoklum
> Here is a short snippet of some abstract C++ code. As you can see, that is a
> code from the Windows DLL

I stopped reading at this point.

But, ok, I didn't really. I also noticed the code was quite dated /
inopportune:

* Has a "X-er" class - which probably shouldn't exist in the first place.

* Using raw `delete` and `new`

* Using unions instead of std::variant's

* Using C library calls instead of `<algorithm>` functions (memset vs std::fill)

* Using `rand()` instead of the standard library's facilities (even though it's broken [https://www.youtube.com/watch?v=LDPMpc-ENqY&t=329s](https://www.youtube.com/watch?v=LDPMpc-ENqY&t=329s))

So... it's outdated and inelegant C++, regardless of any actual errors.

------
Iwan-Zotow
Language itself is made exclusively from dark corners and pitfalls.

~~~
human20190310
C++ seems to have this never-ending cycle where it keeps introducing fixes for
deficiencies that people have found a way to work around, but which in turn
create their own problems...

E.g. C++11's std::move, which may have partially solved the problem of copying
objects (which everyone had their own way of avoiding anyway), but introduced
its own puzzles about the validity of the objects after the move.

~~~
kllrnohj
> but introduced its own puzzles about the validity of the objects after the
> move.

In practice it's really not a puzzle. Most of the time you're using std::move
it's because you don't care about the object you moved from, you're about to
drop it on the floor.

The other times you either manually reset it or just read the docs of the type
to find out what it says the state will be after move. It's not really any
different from any other method documentation on a class.

unique_ptr (or other unique_* types) are vastly worth it, which did not
otherwise have a way to work prior to C++11's move semantics.

~~~
human20190310
It's a puzzle; observe 8 years of people (with 5 and 6 digit reputation!)
debating the details in the comments:

[https://stackoverflow.com/questions/3413470/what-is-
stdmove-...](https://stackoverflow.com/questions/3413470/what-is-stdmove-and-
when-should-it-be-used)

~~~
Asooka
That's an incredibly open-ended question, so of course there's debate. I'm
amazed it hasn't been locked already.

------
z_open
I write C++ for a living but feel out of the loop. Do people still select C++
for new projects? Seems a waste when so many people have put effort into
replacing it with something modern. I still learn dark corners and pitfalls
almost weekly. It also feels hard to tell when something is going to be a
performance hit.

~~~
jupp0r
I write C++ for a living and I think you should give it a try. If you stick to
the core guidelines and avoid 95% of the language, it's actually pretty nice.
I'd prefer Rust for most things I'd use C++ for, but there are definitely
areas where it shines (look at boost::hana, which gives you a unified way of
handling compile time and runtime computations, for example).

~~~
FPGAhacker
Do you have a link or reference to the core guidelines?

~~~
jupp0r
[http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)

~~~
FPGAhacker
Awesome, thank you.

------
altmind
I really like C++FQA that covers a lot of inconsistencies and shortcomings in
C++ design [https://yosefk.com/c++fqa/](https://yosefk.com/c++fqa/)

~~~
jcranmer
The C++FQA is not a terribly good resource. It's centered around a point-by-
point rebuttal of a FAQ resource that's kind of outdated and of questionable
quality to begin with. Modern C++ revisions (starting with C++11) have gone a
long way to cleaning up warts in C++ and fixing issues, and remains pretty
unaddressed in the FQA, which is essentially unchanged from ~2009. As one
concrete example, people complaining about C++ ABI incompatibility are
complaining about something that hasn't been a problem for at least 15 years.

------
hellofunk
This is an ugly code snippet. No one should write C++ that looks like this and
if they do they are asking for problems.

------
otabdeveloper4
> Windows WinAPI shite

Are you kidding me? What's next, EBCDIC and zOS?

~~~
f00zz
Yeah. I was expecting something about C++, but the article is mostly about
Win32 dynamic linking issues.

