Jump to content

  • Log In with Google      Sign In   
  • Create Account


NULL vs 0


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
45 replies to this topic

Poll: NULL vs 0 (81 member(s) have cast votes)

When nullptr isn't available, which do you prefer? Why?

  1. NULL (48 votes [59.26%] - View)

    Percentage of vote: 59.26%

  2. 0 (29 votes [35.80%] - View)

    Percentage of vote: 35.80%

  3. Custom type (4 votes [4.94%] - View)

    Percentage of vote: 4.94%

Vote Guests cannot vote

#1 Servant of the Lord   Crossbones+   -  Reputation: 17130

Like
4Likes
Like

Posted 14 December 2012 - 01:29 PM

[forked from Problems with my custom linked list class]

In another thread, I gave this advice:

Don't compare to 0, compare to NULL (or if using C++11, compare to nullptr). It describes your intent better.


Another forummer responded,

...I always thought the same thing you just said there. Though I posted a basic Linked List code couple weeks ago and was using NULL instead of 0 and someone who said he was a TA at a University kept saying that I should not be using NULL in C++, use 0. Good to know that what I learned to use NULL still seems to be right. Also I do use nullptr when I can but the University Compilers don't support C++11 yet.


So I'd like to hear other people's thoughts on it as well.

 

My thoughts are purely based on describing your code intent. 0 implies working with numbers, whereas NULL implies working with pointers; even though pointers are a number, their usage and purpose is different enough that instantly discerning what is what makes code (very slightly) easier to read.

Example:
this->object = 0;
Is 'object' an integer index into an array where the object is found, or is it a pointer to the object itself? Granted, better naming also helps alleviate this confusion, but there is no denying that strict usage of NULL and 0 would help where improper naming causes confusion.

Looking for an alternative perspective, Bjarne Stroustrup says this:

In C++, the definition of NULL is 0, so there is only an aesthetic difference. I prefer to avoid macros, so I use 0. Another problem with NULL is that people sometimes mistakenly believe that it is different from 0 and/or not an integer. In pre-standard code, NULL was/is sometimes defined to something unsuitable and therefore had/has to be avoided. That's less common these days.
If you have to name the null pointer, call it nullptr; that's what it's called in C++11. Then, "nullptr" will be a keyword.


So his complaints are:
  • Macros are evil
  • People are ignorant
  • Older compilers are broken
All valid-ish points. Here are suggested fixes:

Macros are evil
The problems usually associated with macro mis-use doesn't apply to a single '0'. 0 cannot be accidentally be used in any way that I can think of, which might mess up operator precedence or anything like that.

But if you are absolutely intent on avoiding macros, use a constant:
const size_t MyNull = 0;

People are ignorant
Perhaps, but the key then is to educate them. Either that, or don't let them near your code, since there are more dangerous issues in C++ that ignorance of NULL.

Older compilers are broken
So use a modern compiler? Older compilers mess up in other ways as well. Shall we not use the parts of the standard that older compilers got wrong?

However, he does make a good point about "If you have to name the null pointer, call it nullptr; that's what it's called in C++11."
If, for some reason, you are set against using NULL as a macro, and decided to use a constant, you might as well use this as your constant:
#if __cplusplus < 201103L
	 const size_t nullptr = 0;
#endif
It'll only be defined (I think) if C++11's nullptr is not available.

 

When you add C++11's nullptr into the mix, nullptr is obviously the superior choice because not only does it declare your intent, but it also provides additional type-safe protections. But between the outdated NULL and 0, what are your thoughts on the matter?

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.

[Fly with me on Twitter] [Google+] [My broken website]

All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.                                                                                                                                                       [Need free cloud storage? I personally like DropBox]

Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal


Sponsor:

#2 Martins Mozeiko   Crossbones+   -  Reputation: 1413

Like
5Likes
Like

Posted 14 December 2012 - 01:33 PM

Defining nullptr as size_t is not a good idea (will it work at all for assignments to pointer?)
Better use this: http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr#Solution_and_Sample_Code
const // It is a const object...
class nullptr_t
{
  public:
    template<class T>
    inline operator T*() const // convertible to any type of null non-member pointer...
    { return 0; }

    template<class C, class T>
    inline operator T C::*() const   // or any type of null member pointer...
    { return 0; }

  private:
    void operator&() const;  // Can't take address of nullptr

} nullptr = {};


#3 frob   Moderators   -  Reputation: 18857

Like
2Likes
Like

Posted 14 December 2012 - 02:02 PM

NULL specifies intent.

There are also a few edge cases (especially on embedded hardware) where 0 != (void*)0 and the automatic conversion doesn't quite work right.
Check out my personal indie blog at bryanwagstaff.com.

#4 samoth   Crossbones+   -  Reputation: 4510

Like
-2Likes
Like

Posted 14 December 2012 - 02:27 PM

I'm using 0 even though my compiler supports nullptr, and every single time I have a bad conscience (knowing that nullptr is the correct-correct thing to use). However, 0 is quick to type, and it's an idiom I've gotten used to during the years. The C++ standard makes the conversion from a zero literal to the null pointer of a type well defined too, so meh... one cannot even argue that it's wrong to use 0. Actually, it's quite correct.

NULL on the other hand has two properties that turn me off. It's a macro, and it's an all-caps name. I really, really, really hate reading all-caps text.

#5 smr   Members   -  Reputation: 1554

Like
1Likes
Like

Posted 14 December 2012 - 02:28 PM

Zero (0). Because what would Stroustrup do?

Edited by smr, 14 December 2012 - 02:31 PM.


#6 Álvaro   Crossbones+   -  Reputation: 11881

Like
0Likes
Like

Posted 14 December 2012 - 02:52 PM

0 because I never know what header has the definition for NULL. I know it's a lame argument, but it's true. Then I read that Stroustrup prefers 0 also, so 0 it is.

Also, it doesn't really matter much for how I write code these days. For the most part I only use null pointers to pass them to functions like time(), or some Unix system calls.

#7 SiCrane   Moderators   -  Reputation: 9387

Like
4Likes
Like

Posted 14 December 2012 - 02:58 PM

Older compilers are broken
So use a modern compiler? Older compilers mess up in other ways as well. Shall we not use the parts of the standard that older compilers got wrong?

This strikes me as an unreasonable argument. If you were in a situation where "use a modern compiler" was an option, then you wouldn't be in a situation where you would need to choose between NULL and 0 in the first place.

Personally, I use 0 as I've run into too many C programmers who couldn't be bothered to include a compiler header that defines NULL and would stick #define NULL ((void*)0) in their own code.

#8 Washu   Senior Moderators   -  Reputation: 4469

Like
3Likes
Like

Posted 14 December 2012 - 03:28 PM

0. Or nullptr in modern C++.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX


#9 Geometrian   Crossbones+   -  Reputation: 1428

Like
1Likes
Like

Posted 14 December 2012 - 03:31 PM

NULL all the way. My thoughts:

NULL does imply intent in a way that is far superior to 0. It is clean, concise, and like its C roots, is consistent with macro naming conventions. It is much easier to accidentally create ambiguity with 0 as in the OP's example. While I agree that "nullptr" might also adequately solve the semantic problem, it is redundant to NULL's precedent, longer to type, and doesn't stand out as much. Also, it is not supported everywhere yet--and while I appreciate that that means you should get a better compiler, why do we even need a new keyword when we already have one?

As a macro, it can easily be changed for platform-specific purposes, and does not incur the overhead of a full variable, even with a crappy compiler. I suppose pathologically contrived macro redefinitions could cause a problem, but this could be solved in C++ by making NULL a keyword instead of a macro--not making a completely new keyword that does exactly the same thing.

Further, macros are not inherently evil. When used incompetently, sure, they can cause many many problems. But macros were invented to make coding easier and more understandable. Whether using macros to write most of your code is good practice is a different argument, but in the case of NULL it's basically what macros were invented for--"to abstract away magic numbers without additional runtime overhead".

C and C++ are different languages, but there's no fundamental reason why they should be more different than they need to be. Regularly, I write small modules in C, refactoring into C++ when a more elaborate design becomes necessary. NULL and nullptr serve the same purpose, so why can't we use the one that everyone already uses? Using nullptr implies that tons of perfectly good, readable code would need to get rewritten to handle the new standard--unless of course NULL and nullptr end up coexisting side-by-side, which would be worse.
And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.

#10 saejox   Members   -  Reputation: 714

Like
0Likes
Like

Posted 14 December 2012 - 03:54 PM

0 because easier to write.
No need read too much in to this simple issue.

nullptr in c++11 is nice tho.

#11 SiCrane   Moderators   -  Reputation: 9387

Like
5Likes
Like

Posted 14 December 2012 - 03:58 PM

Basically the reason that nullptr exists is because the type of NULL isn't a pointer type, it's an integer constant expression. If you have an overloaded function void foo(int); and void foo(void *); then foo(NULL) calls the int overload rather than the void pointer overload despite the fact that NULL has the implied meaning of a pointer constant. Not a big deal in C when you don't have function overloads, but becomes a problem in C++ where not only do you have function overloads, you have weird template type deductions and what not because NULL is an integer constant.

#12 Martins Mozeiko   Crossbones+   -  Reputation: 1413

Like
0Likes
Like

Posted 14 December 2012 - 04:34 PM

SiCrane - I don't think it's true.
GCC (also Visual Studio) defines NULL like this: "#define NULL ((void *)0)" in stddef.h.
So:
c:\ test>type a.cpp

#define NULL ((void*)0)
void foo(int);
void foo(void*);
int main()
{
  foo(NULL);
}

c:\ test>g++ a.cpp
C:\Users\XXX\AppData\Local\Temp\ccAUKoxR.o:a.cpp:(.text+0x16): undefined reference to `foo(void*)'
collect2.exe: error: ld returned 1 exit status

foo(NULL) correctly calls foo(void*).

Edited by Martins Mozeiko, 14 December 2012 - 04:38 PM.


#13 Flimflam   Members   -  Reputation: 657

Like
-1Likes
Like

Posted 14 December 2012 - 04:40 PM

You know, I've always wondered, when they created the C++11 spec, why did they create "nullptr" instead of just using the reserved but functionless "null" keyword that already exists?

Was it because people were creating their own functionality for it via macros or what have you?

#14 Mussi   Crossbones+   -  Reputation: 1700

Like
1Likes
Like

Posted 14 December 2012 - 04:42 PM

I used NULL in the past, but now I'd just define nullptr if it wasn't available. So that when you transition to a modern compiler, your code base stays consistent.

#15 Álvaro   Crossbones+   -  Reputation: 11881

Like
1Likes
Like

Posted 14 December 2012 - 04:51 PM

You know, I've always wondered, when they created the C++11 spec, why did they create "nullptr" instead of just using the reserved but functionless "null" keyword that already exists?

Was it because people were creating their own functionality for it via macros or what have you?


"null" is a keyword in C++? I didn't know that... Or are you thinking of a different language?

#16 SiCrane   Moderators   -  Reputation: 9387

Like
4Likes
Like

Posted 14 December 2012 - 04:52 PM

SiCrane - I don't think it's true.
GCC (also Visual Studio) defines NULL like this: "#define NULL ((void *)0)" in stddef.h.

((void *)0) is not a legal definition for NULL in C++. It is a valid definition for NULL in C. So MSVC's NULL definition looks like:
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
If you try using the ((void *)0) definition in C++ you get errors doing simple things like int * p = NULL; since a void * can't be assigned to a non void pointer without a cast in C++. See sections 18.1 in the C++98 and C++03 and 18.2 in the C++11 standards where the footnotes specifically say that (void *)0 is not a legal definition for NULL.

#17 Flimflam   Members   -  Reputation: 657

Like
0Likes
Like

Posted 14 December 2012 - 04:55 PM


You know, I've always wondered, when they created the C++11 spec, why did they create "nullptr" instead of just using the reserved but functionless "null" keyword that already exists?

Was it because people were creating their own functionality for it via macros or what have you?


"null" is a keyword in C++? I didn't know that... Or are you thinking of a different language?

No, not officially. My wording was a bit misleading. In fact thinking back, I'm just confusing the functionality of an old compiler that had reserved it. I'm unaware if any others have since.

#18 Martins Mozeiko   Crossbones+   -  Reputation: 1413

Like
0Likes
Like

Posted 14 December 2012 - 05:21 PM

((void *)0) is not a legal definition for NULL in C++. It is a valid definition for NULL in C. So MSVC's NULL definition looks like:

Yes, you're right. Sorry, I misread that #ifdef...

#19 Khatharr   Crossbones+   -  Reputation: 2819

Like
0Likes
Like

Posted 14 December 2012 - 06:27 PM

I actually was unpleasantly surprised recently when I was writing templates with no header inclusions and I discovered that NULL is not a keyword. (I always thought it was part of the language for some reason.)

In such files I took to saying:
[source lang="cpp"]#ifndef NULL#define NULL 0#endif[/source]

But I'm not using C++11 at the moment, so I don't have nullptr. There's some interesting things to consider in this thread, though. Thanks for starting this, SotL.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#20 wqking   Members   -  Reputation: 756

Like
0Likes
Like

Posted 14 December 2012 - 08:00 PM

Always NULL.
There are plenty of reasons, I listed some reasons in my early blog.
http://cpgf.org/blog/why-i-prefer-null-over-0-as-null-pointer.html

My primary three points,
1, Reason 1, NULL is self explained.
2, Reason 2, C++ standard saying NULL is 0 doesn't mean null pointer is 0
3, Reason 3, C++11 supports nullptr, everyone will prefer nullptr to 0, then why don't we use NULL than 0 in pre-C++11 era?

And I have tough time to conver C++ code with 0 as pointer to Lua code, but maybe only I do it :)

However, nothing is correct or wrong, it is very subjective opinion, IMHO.

http://www.cpgf.org/
cpgf library -- free C++ open source library for reflection, serialization, script binding, callbacks, and meta data for OpenGL Box2D, SFML and Irrlicht.
v1.5.5 was released. Now supports tween and timeline for ease animation.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS