

C++ Hints - PVS-Studio
http://cpphints.com

======
halosghost
Many of these look like great suggestions; however, I am always a little
worried when I run into “C/C++”. I realize many of the suggestions in this
seem to be fairly compatible with both languages (some of them certainly
aren't; e.g., see the one on the front-page which is on the topic of
exceptions and destructors), but I think it is about time we all accept that
they are disparate languages and stop treating them as mostly-interchangable
or compatible languages.

At the very least, the continued reinforcement of the myth that C++ is “just
an extension” that sits on top of C really needs to stop. There is no real
benefit from it and it can cause plenty of damage when developers incorrectly
assume they have adequate knowledge from one of the two languages to be
profficient in the other.

~~~
gue5t
Agreed. "C/C++" as a term tends to be a crutch for cases where the author
hasn't thought about the specifics of how their statement might apply
differently to each language (much less the various versions and
implementations of their specs) and would rather be vague than wrong (but is
often both). "Both C and C++" (for exactly those two) or "C-family languages"
(for C, C++, obj-C, at least, and as a more general term overall) are more
often what people should be reaching for.

------
mikeash
There's some good stuff here.

I'd like to offer a critique of the proposed solution to casting pointers to
integer types, though. The post suggests using uintptr_t or similar when
manipulating pointer types, to avoid 64-bit troubles. For the particular case
of adding a number of bytes to a pointer, I'd recommend using char* instead.
That bypasses the whole question of "what integer type is big enough?" and
helps avoid mistakes like accidentally dividing or multiplying the number, or
passing it in to something that wants an integer.

------
_kst_
The advice about storing pointers in integers:

[http://cpphints.com/hints/7](http://cpphints.com/hints/7)

is poor. It points out that converting a pointer value to "unsigned long" so
you can perform arithmetic on it is a bad idea -- which is perfectly correct.
But it advises just using a different integer type, such as "uintptr_t". The
correct solution is to use pointer arithmetic. Don't store pointers in
integers, store pointers in pointers; that's what they're for.

I've sent a comment to the author.

~~~
w0000t
Yep, C doesn't define that uintptr_t can be modified and converted back to a
pointer. It is only for storage.

~~~
w0000t
.

------
btrask
We need more and better warning options, and more of them to be enabled by
default (use -Wall -Wextra -Werror, please!). I have nothing against PVS-
Studio but I think promoting static analyzers will actually do more harm than
good in the long run. Static analyzers are just compiler warnings that you
have to pay for and then forget to run.

~~~
halosghost
Actually clang has a static analyzer that is free and pretty usable.

Additionally, I religiously use `-Weverything -Werror` for C and specifically
disable warnings I know to be false positives. People have told me that it is
excessive, but I have found that it leads me to write dramatically more stable
code in the long run.

Clang is also planning to add some additional options in the style of
-fsanitize that will allow for compile-time checking and failure on detection
of undefined behavior. That is a feature I am incredibly excited for! Having
runtime-checks for UB is nice, but bloats the resulting executable quite a bit
(not to mention the performance penalty). But having compile-time checks would
be awesome; adds a little more work for me if I've been relying on UB, but
makes the code better in the long run and doesn't affect run-time unless the
change was necessary anyway.

------
nitin_flanker
This is awesome. SUper Awesome for a rookie like me.

