User forums > Help

NULL undefined

<< < (6/8) > >>

wwolf:
killerbot,

I might remember wrong, but I think the standard itself probably already requires NULL to be defined in more than one header. And if it is defined in non-standard headers (such as header that are not listed in the C or C++ standard) they are bad implementations. People should stop defining NULL and include the appropriate standard header instead...

BTW it is no problem (in practice) if they define NULL in a standard way, and if they only define it if it has not been defined already.  Which is (I think) fairly simple:

#ifndef NULL
#ifdef __cpluplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
#endif

But as the standard clearly moves the responsibility of defining NULL and its replacement tokens into the "rights" of the implementor (in our case the C and C++ standard library implementor) the above code must be replaced by the inclusion of the appropriate standard header. Yes, it works in most cases but it is just unnecessary code duplication - and it is error prone. For example if NULL gets defined to be nullptr, the above code will not work anymore properly.

thomas:
My personal issue with NULL is that it is a macro, and I just don't like macros. That's it.
Yes, there are good uses for macros (anyone who ever needed offsetof(), will agree), but most macro uses are... what was that word above, bull feces? :)
A macro replaces some text of yours with some other text. You don't know if it happens, you don't see what happens, and the preprocessor doesn't care about the language's grammar, namespaces, or much of anything else. This can be a desaster, but it can also be a good thing in a few rare cases. It really depends.

If I remember correctly, there was a Stroustrup quote 10+ years ago that said something similar in respect to NULL. I think it was like "use what you want, it's the same thing, but I'm using 0 because I don't like macros".

That's the correct way of looking at it, in my opinion. What does it matter if NULL is standard or not? It is a descriptive token. If you want something to be descriptive, make it NULL. If you don't want that, make it 0. Whatever you do, it's ok.
WM_CLOSE and WM_LBUTTONDOWN are not standard, but they prevent you from wondering "What the hell do 16 and 513 stand for, what is going on here?". Or think about expressions like INT_MAX-1
To me, if(ptr == 0) is pretty darn obvious, and I prefer this form in almost all cases. To other people, it is maybe not so obvious. In either case, I would use const in preference to #defines. While #defines have their good uses, in many cases, a const performs the same, but safer.


--- Quote from: oZZ on September 16, 2007, 03:17:30 am ---I #define nullptr 0 for the time being.  It's being added to the C++ standard in the next revision as something different than 0 to give a little more safety to null pointers, so it's probably a better way to do it for now.  Just remember to remove the #define when C++0x hits.
--- End quote ---
What is wrong with static const void *nullptr = 0;? It obviously won't do for foo_t* bar = nullptr; without a cast, but if(foo == nullptr) should do just fine, and would bark if it encounters pointer/integral mismatches.

If you want to be able to assign nullptr too, it obviously gets more complicated... but you could write something like: template<typename T> void NullPtr(T& ptr) { ptr = static_cast<T>(const_cast<void*>(nullptr)); } and then NullPtr(some_pointer); to zero that pointer. I haven't tested this, but I guess it should just work.

wwolf:
Yes, it is a macro. However the general bashing of macros does not apply to it. Why? Because it represents something that is GLOBAL, that must not obey namespaces or anything like that.

I know that Bjarne does not like the preprocessor, however since he has failed to provide (originally) a better solution (that can do the same things) we need to use it, since we have nothing else. This is my general comment. And if you look at (for example) the Boost Preprocessor Metaprogramming Library you will see, that the preprocessor has its place.

As for 0 vs. NULL: the fact that NULL is a macro is irrelevant here. Even if Bjarne says otherwise.  What you decide between is using a named entity versus a literal integer.  To me, after approx. 7 years large scale C++ development and integration experiences, the choice is obvious. Names are good. Literals are bad. They hurt where it really hurts. :)

Attila a.k.a. WW

wwolf:
must not obey ==> does not need to obey

Me speeky no Engelishe

dempl_dempl:
Muahahahahahahaha :lol: :D

wwolf and killerbot:
You're both mad!!! mad!!!


wwolf : you're also biggest poseur. I know this guy bla bla bla ... I know that guy .. oooo ... look at me bla bla bla :p

Navigation

[0] Message Index

[#] Next page

[*] Previous page