NULL vs. 0

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

There are several good reasons.
The best one : It is more human-friendly... You know the intent of the
programmer (assuming that the programmer uses NULL in pointer contexts
only).

I think that NULL is human-unfriendly precisely because that: I have seen a
lot of code where people mixes NULL used as pointer and used as char (I
suppose they suffer a confusion with the ascii NUL char name). Some people
even write things like:

char * txt;
(...)
if (txt == NULL || txt [0] == NULL)

I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.

The point of type safety is that the compiler can help to avoid some
mistakes. As my previous paragraph shows, NULL does not prevent some
obvious mistakes. It even help create new ones because of the name
confusion with NUL.

 

[Alf P. Steinbach]

* Noah Roberts:

A rather disagree that struct indicates POD. It is an artificial
indicator at best, one easily broken as the language makes no such
distinction. I don't think this is something that can be depended on
at all and therefore is no indicator that we have a POD vs. non-POD.

Whether struct indicates POD depends on your conventions.

Be aware that struct indicates POD to many people.

Except in short example code.

 

[Noah Roberts]

* Noah Roberts:

Whether struct indicates POD depends on your conventions.

Conventions like that are unenforceable at best. It is also a rather
silly distinction to make especially in light of tr1 and type traits.
Algorithms can be designed to take advantage of PODS in whatever form
they take when necissary (yes, classes can be PODS as you well know).

struct being a POD is a bastard child of C. It is a concept best
forgotten. The struct keyword is a poor indicator of PODness that has
no basis in the language.

Be aware that struct indicates POD to many people.

Well many people do silly things all the time. Those assumptions are
invalid and shouldn't be made. The fact that most people do has no
impact on the validity of the claim.

Except in short example code.

Size of the code doesn't really matter except that altering a struct to
become a class, just to match some silly idea that structs are PODS
only, in a large project is just crazy. If some struct suddenly needs
a constructor or virtual function then add it...don't do a bunch of
pointless work to make it use the class keyword instead of struct.

Simply put, this "convention" can't be depended on even if it is a
convention. You'll spend more time trying to hold to it than there is
any benifit in doing so. You'll also spend a lot of time trying to
enforce this artificial constraint for every new person comming in that
is not aware of or doesn't understand the distinction...and the later
is easy to see happening since there isn't one.

 

[tedu]

You can use something like:

template <class T> T * NullPtr () { return static_cast <T *> (0); }
template <class T> bool isNull (T * ptr) { return ptr == 0; }

That way you have easy searchability and type safety for a low price.

except for the part about your code not compiling anymore.

template <class T> T *NullPtr() { return static_cast <T *>(0); }
struct str {
int a;
};
void foo() {
int *i = NullPtr();
str *s = NullPtr();
}

g++ -c t.cc
t.cc: In function 'void foo()':
t.cc:6: error: no matching function for call to 'NullPtr()'
t.cc:7: error: no matching function for call to 'NullPtr()'

 

[Jakob Bieling]

Julián Albo wrote:

except for the part about your code not compiling anymore.

It will, if used correctly:

template <class T> T *NullPtr() { return static_cast <T *>(0); }
struct str {
int a;
};
void foo() {
int *i = NullPtr();

str *s = NullPtr();

}

regards

 

[Rolf Magnus]

I would like to say that the fact that NULL is not type safe in C++
doesn't mean that it must not be used... Even if the compiler doesn't
make any difference between NULL and 0, programmers do.

Yes, and that's exactly the problem, though I would turn that sentence
around:

Even though programmers often do make a difference between NULL and 0,
compilers don't.

 

[Rolf Magnus]

except for the part about your code not compiling anymore.

It does not compile because you are trying to use it in a non-typesafe way.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

except for the part about your code not compiling anymore.

*Your* code does not compile. Mine does.

 

[tedu]

It will, if used correctly:

int* i = NullPtr <int> ();

ok, now it really seems like a nuisance to use (for me). i had
misinterpreted the intent was almost more like a drop in NULL
replacement of some sort. this clears up some of the why, thanks.

 

[I V]

ok, now it really seems like a nuisance to use (for me). i had
misinterpreted the intent was almost more like a drop in NULL
replacement of some sort. this clears up some of the why, thanks.

If you don't want to explicitly specify the type of the null (and I can't
immediately think why you _would_ want that), you could do:

class null_type
{
public:
template<typename T>
operator T*() const
{
return 0;
}
};

const null_type nullptr = null_type();

 

[Markus Schoder]

Yes, and that's exactly the problem, though I would turn that sentence
around:

Even though programmers often do make a difference between NULL and 0,
compilers don't.

That's not quite true. If I compile

#include <cstddef>

int main()
{
return NULL;
}

I get:

nullptr.cpp: In function 'int main()':
nullptr.cpp:5: warning: converting to non-pointer type 'int' from NULL

so it's a quality of implementation issue.

 

[Noah Roberts]

That's not quite true. If I compile

#include <cstddef>

int main()
{
return NULL;
}

I get:

nullptr.cpp: In function 'int main()':
nullptr.cpp:5: warning: converting to non-pointer type 'int' from NULL

so it's a quality of implementation issue.

Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.

 

[Rolf Magnus]

Hmmm...I think that actually violates the standard. NULL is defined as
a macro resolving to a "null pointer constant", which is defined as an
"integral constant" resolving to 0.

So? That's what the compiler does in the above case. It just warns that NULL
was used in an integer context. I don't think the standard disallows that.

 

[Phlip]

So? That's what the compiler does in the above case. It just warns that
NULL
was used in an integer context. I don't think the standard disallows that.

Would cstddef violate the Standard if it presented this?

#define ((void*)0)

That appears to be what it's doing, and it's not an integral constant, it's
a constant address.

 

[Noah Roberts]

Would cstddef violate the Standard if it presented this?

#define ((void*)0)

That is a certain violation of the C++ standard. The C++ standard
explicitly states that it is not that.

Is the implementation free to display diagnostics about things that are
well formed?

 

[Rolf Magnus]

Would cstddef violate the Standard if it presented this?

#define ((void*)0)

ITYM:

#define NULL ((void*)0)

That would be a violation.

That appears to be what it's doing, and it's not an integral constant,
it's a constant address.

That's not what the compiler (probably gcc) is doing. On my system, NULL is
defined as:

#define NULL (__null)

with __null being a built-in integer constant that resolves to 0, but
generates a compiler warning if used in an integer context.

 

[Markus Schoder]

That is a certain violation of the C++ standard. The C++ standard
explicitly states that it is not that.

That would be a violation and that is not what the compiler does. It uses
some compiler trickery that is otherwise transparent to the user.

Is the implementation free to display diagnostics about things that are
well formed?

Aren't warnings pretty much always about well-formed constructs? If it
weren't well-formed it would have to be an error.

 

[Andrey Tarasevich]

...
Is the implementation free to display diagnostics about things that are
well formed?
...

Of course. That's what warnings are in a traditional implementation:
diagnostic messages about things that are well-formed.