The macro NULL is an implementation-defined C++ null pointer
Implementation-defined !!!! --> NOT standard.
It shows up in so many headers, why ... because it is not standard. People just define it in headers because they are used to using it. I have been attending many talks of Mr Stroustrup [EDIT : fixed typo in Bjarne's name] where he is stressing it is not standard [maybe just for the fact that it is not portable], in his code samples he writes 0.
In fact it is a real violation of strong types.
char* p = NULL; char* != void* [in case it is defined as just 0 it would be ok].
If it is so standard, why are there so many compilers who do NOT define it, some do it in stdio.h others in stdlib.h, correction : cstdio and cstdlib. Trust me, I have been using a lot of compilers and I have seen code break because of the lovely NULL not being defined.
Darn right let's include a huge header file to get the NULL define, and on the other hand we pimpl and other stuff to get less include dependencies, but let's break all that for that nice lovely NULL.
If I recall correctly, they are thinking about a *template* for something like nullptr, but I am not sure.
For sure it will be a keyword --> so part of the language :
nullptr - C++0x keyword for the null pointer. It is not an integer. It can be assigned only to pointers.
a define is not part of the language, it is the same story that some compilers have a define for PI and others don't.
And I have heard/read similar things from Sutter, Meyers about NULL not being standard. I am wrong if they didn't tell/write the correct stuff [maybe just for the fact that it is not portable]. But I will never ever use NULL for sure as those gurus suggested. I want my code to be clean not including headers (which in turn include other headers) for some freaky define where I kind write something as simple as :
char* p = 0;
By the way, NULL and 0 have another problem, but when you write 0 it becomes more apparent :
f(int);
f(char*);
f(0); ---> which one am I calling ......... ==> we call f(int) !!!
if we want to call f(char*) we should :
f(static_cast<char*>NULL);
f(static_cast<char*>0);
And this is where that keyword nullptr will help us out, because it is not an int and can only be assigned to pointers.
Which brings us to :
f(int*);
f(char*);
--> f(nullptr) --->
??
On the other hand, we better follow Meyers advice : Avoid overloading on a pointer and a numerical type. See Item 25 in his book "Effective C++". Where he discussed 'what is 0 (pointer) '
Another note : NULL is a preprocessor symbol as said --> so not the language.
See C++ Gotchas from Dewhurst : Gotcha 9 : Using bad language :
The trouble was that NULL would be defined in various ways on different platforms :
#define NULL ((char*)0)
#define NULL ((void*)0)
#define NULL 0
These various definitions wreaked havoc with portability of C++ programs [My note : As said already above]
In fact there is no way to represent a null pointer directly in C++, but we're guaranteed that the numeric literal 0 in convertible to a null pointer. That is what C++ programmers traditionally used to ensure the portability and correctness of their code. Now the standard indicates that definitions like (void*)0 are not allowed.
Wrapping up : just avoid using NULL, as said it is not professional and makes your code break on different platforms.
Which header should bring that NULL (null.h ?? woops doesn't exist) ?
Is it now in the standard or not, I still believe it is not, standard means it is something that is guaranteed, not implementation specific. They keyword 'while' guarantees me something, but the preprocessor symbol NULL guarantees me nothing.
Really, avoid NULL, use 0. There are only benefits.
d also the C++ language; and its use is professional: it makes software more readable, less ambiguous and more maintainable.
Yes really, it breaks code. i wonder why Dewhurst called his topic 'Bad language'.
Just tell the original poster which header to include, and tell him that the include of that header will bring compilation time down [for the little example it is no issue, but on bigger software] just because NULL is professional. You are also very welcome to port his code then to embedded devices because it for sure will break [have seen it several times] because that iostream header doesn't even exist, or it doesn't bring the NULL.
Meyers, Stroustrup, Sutter, Alexandrescu, Dewhurst ... , they all use 0 and not NULL. Those guys live, breath C++, but it seems they are unprofessional because they don't use NULL.
I respect your opinion but I totally disagree. I prefer fast compiling , portable , sound C++ code. Your NULL use will make everything explode, sorry.
If we look at the code we want to see immediately if something is a "null pointer constant" or the zero integer.
This brings nothing :
char* p = 0; // or NULL (what's the difference to the eye
) it is all on the same line.
if(p== NULL) and if (p!= NULL)
just write
if(!p) and if(p) // we know p is a pointer so it is very obvious what the test does, no need to type those extra things.
With the null pointer keyword coming up, I agree then that should be the style to use, but then it comes from within the language, no need to include something [just like 'while' comes without any include].
#define nullptr 0
Suggestion : put it in your personal namespace so you don't get any conflicts. Once the C++0x is there you can replace all MyNameSpace::nullptr by nullptr. So make a constant out of it instead of a define. And that constant lives in its namespace, your define is now everywhere and can fight with other doing a similar thing.
NULL being defined in several headers ---> one definition in one place seems no longer a sound advice
Once again another sound programming idiom broken thanks to those nice 4 characters, N U L L .
