C++ Hints

by PVS-Studio • 11 years ago

51 9 11 years ago

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

halosghost2• 11 years ago

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• 11 years ago

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• 11 years ago

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.

btrask• 11 years ago

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.

halosghost2• 11 years ago

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.

_kst_• 11 years ago

The advice about storing pointers in integers:

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.

w0000t2• 11 years ago

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

w0000t2• 11 years ago

C++ Hints

Related Stories