C++ Hints(cpphints.com)
cpphints.com
C++ Hints
http://cpphints.com
5 comments
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.
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.
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.
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.
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.
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.
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.
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.
This is awesome. SUper Awesome for a rookie like me.
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.