This is a good time to remind that the time when pointers was initialized to 0 should now been seen as a time past, if possible.
In the new standard, all pointers should be initialized to nullptr, provided your compiler supports it (GCC and MSVC does).
So avoid using 0 or NULL unless a) your compiler doesn't support it or b) you are using legacy code.
Using 0 for pointers is an Evil™ thing that defeats the type system.
Originally Posted by Adak
O_o
Now that's a good way to plug the C++11 standard facilities.
Soma
I agree but went with 0 over nullptr because the OP stated he was working with MSVC 2008, which (unless I'm horribly mistaken) has no C++11 support whatsoever.
True, MSVC8 has no C++11 support (MSVC10+, GCC 4.6+).
Anyway, upgrading is nice and will net the support of some of these features. But even if not, I just wanted to point out the existence of such features for reference anyway.
Just to be pedantic, the latest standard does not require that pointers be initialised to nullptr. It provides nullptr as an option for initialising a pointer. The effect is the same as initialising that pointer to zero (or to NULL), albeit with improved type safety. It is therefore a decision for the programmer as to which technique is used - although I agree, if you want a null pointer and can assume a compiler that supports C++-11, it is better style to use nullptr. The thing is: good style is subjective.
There is also a case c) you are required to support compilers that do not support nullptr. Since the majority of existing real-world compilers do not yet support C++-11, it is not necessarily a bad thing (assuming you want a null pointer) to write code that uses 0 or NULL rather than nullptr.
In software development, nothing is really Evil (with or without the ™), if it can be used to meet a goal in a maintainable manner.
All that said, I consider null pointers are one of the most over-used and abused features of both the C and C++ languages. Most instances of null pointers can be avoided through a bit of thought (eg by using the standard library containers rather than a "roll your own" linked list, avoiding "construct now, initialise later" approaches, destroying a pointer by allowing it to pass out of scope when the object it points to is released, etc, etc).
Agreed. And it applies to more than just pointers. I'm personally so very very sick of stumbling across functions / methods where the programmer has declared a gazillion local variables at the top, assigned default values to some of them and then, somewhere way down in the function, possibly actually uses some of them. I know, you aren't necessarily just talking about function-local variables, but God I swear it's one of my favorite things to hate.
I agree with you on that, antred. My avoidance of "construct now, initialise later" approaches is a particular case of avoiding defining variables before they are needed.
Even in C, before C99, I would avoid things like defining variables at the top of a block. Doing that required more careful use of scope (including breaking up code into smaller functions) but I usually found the effort paid off in simpler and more maintainable code.
