On Wed, 5 Jul 2006 11:09:58 -0400, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
[...] 0p or null would certainly help clarify the "null-pointer" issue.
I assume you have done something similar to moving code to x86_64?
Not in the sense you probably mean (I know of people who use my code on 64-bit platforms though). I've never followed Stroustrup's advice to use "0", because I had a (slight) hope that I could grep for "NULL" some day in the future and replace it with something better: this is from an old post of mine on c.l.c++.m (the message is very long, so I'll directly quote the relevant part here) As to using 0 vs. NULL I prefer NULL (mainly in the hope that I can grep and replace it easily if a true null pointer constant will be introduced in C++) [...] If the language had a true, type-safe, overload-compatible null pointer constant then we could start discussing on real technical basis. The NULL definition was an error. They wanted to prohibit (void*)0, because it implied a special case of implicit conversion from void* to object pointer. But they probably didn't realize they were replacing it with something requiring a special case for 'int and any integral or enumeration type' -> pointer, which is worse. enum { e = 32 }; const int null = !!!!! !!!! !!!! !!!!!! !!!!!!!! ! ! !! !! !! !! !! !! !!!!! !! !! !! !! !!!!!! !! !!!!! !! !! !! !! !! !! ! ! !! !! !! !! !! !! !!!!! !!!! !!!! !!!!!! !! (e >> 6) * ('9'-'1') * sizeof(char); void (*p)() = null;
So... the rule now is to use NULL anytime a vararg function is being called... 0 otherwise... until we run into the next problem...
That doesn't solve the problem if NULL is used from C++. As to nullptr... the current accepted naming style is/was (a) avoiding abbreviations (b) separating different words with underscore. That suggests "null_pointer" but... hey we have shared_ptr, so why not null_ptr? Oh no, we don't like underscores :) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]