|
NOV
22
2005
|
NULLFrom the KOrganizer coding style guidelines: "A null pointer is 0, not 0l, 0L or NULL. Once again, this is C++, not C." Hmmm. If you get bored sometimes, try to compile with gcc something like "void foo( int ); ... foo( NULL );" and see what happens. And then what happens with "foo( 0 );" (and yes, I remember fixing a bug in KDE caused by this). Ok, NULL is not what it really should be, but C/C++ have many small weird things (ever wondered why binary operators | and & have so stupid priority? It's called backwards compatibility lasting for more than 30 years). Moreover, I wonder, why are symbolic constants C but not C++?
|
 |
Comments
Maybe a keyword in the future
Maybe the next version of C++ will get an explicit keyword for null pointers as proposed by Herb Sutter and Bjarne Stroustrup: http://www.research.att.com/~bs/N1488-nullptr.pdf
If this comes true it will be easier to convert all usages of NULL to nullptr than of 0. This is the reason I use NULL instead of 0 when I have a null pointer.
constants
> Moreover, I wonder, why are symbolic constants C but not C++?
C++ supports symbolic constants. The NULL keyword should be avoided because it's meaning differs between systems. Some systems define NULL as 0, others define it as ((void*)0) This isn't an issue in C, but the more strict type checking in C++ causes problems here.
Not conforming
If there's a system which #defines NULL as (void*)0 for C++ then it's broken. Uses of NULL simply wouldn't even compile then, as C++ doesn't allow converting void* to T* without an explicit cast. Properly #defined NULL for C++ is either 0 (or 0L or some other kind of 0) or something like gcc's __null. In either case it's at least as good as using plain 0.