Re[2]: [lmi] Re: 'NULL' versus '0'

[Vadim Zeitlin]

On Thu, 26 Oct 2006 00:36:20 +0000 Greg Chicares <address@hidden> wrote:

GC> > GC> [...] Anything but 'NULL'....
GC> > 
GC> >  Could I ask why? There must be some argument against it to compensate the
GC> > 2 strong arguments in favour of using it I gave above, mustn't it?
GC> 
GC> Reexamining my viewpoint, I realize that my dislike for 'NULL' dates
GC> back to the nineteen-eighties, when folks argued whether its value
GC> should be '0', '0L', or (after C89/90) '(void*)(0)'.

 Yes, this is exactly what I meant when I said that there used to be a lot
of confusion about this back then. But I think it cleared a long time ago.

GC> However, do you disagree with BS's reasons, given under
GC>   "We recommend that the name of the reserved word be nullptr"
GC> in his paper, for preferring 'nullptr' to 'NULL'?

 This is a matter of habit and convenience. I know I prefer NULL but I
honestly can't come up with any compelling arguments for it, 3 extra
characters to type doesn't count as much in our days of auto-completing 
editors as before. OTOH maybe the extra length still counts sometimes,
especially when you want to keep the lines under 80 characters limit.
But then I can't come up with any reason to prefer nullptr neither, the
only one I can think of is that it makes it absolutely clear that we're
dealing with a null pointer (sic) but any C++ programmer should recognize
NULL as indicating the same thing without problems neither.

GC> If not, I would now propose changing 'config.hpp' as follows:
GC> 
GC>   #else // Not using autoconf.
GC> 
GC> + #if defined __GNUG__
GC> + #   define nullptr __null
GC> + #else  // Compiler not known to support anything like 'nullptr'.
GC> + #   include <cstddef>
GC> + #   define nullptr NULL
GC> + #endif // Compiler not known to support anything like 'nullptr'.
GC> +

 Again, a very minor nitpick is that there might be other compilers doing
the same thing as gcc (although I don't know of any to be honest) and just
using NULL would give us an advantage then, without having to list all of
them (and checking their versions) explicitly.

GC> Of course, that has the same meaning as 'NULL': it's just a matter
GC> of choosing one name for consistent use. But if you still prefer
GC> 'NULL' until ISO adopts 'nullptr', I'm okay with that, too.

 As I said, I personally prefer NULL just because I (and presumably others)
am/are more used to it and because it's shorter. But I realize this is not
a sound enough basis for choosing it.

GC> That said, would it not be even better to use the "library
GC> implementation" in section 1.1 of the 'nullptr' proposal?

 IMO this is over-engineering. As indicated in the paper, using such
implementation would result in very unclear error messages and, another
practical consideration, it could also increase compile time (an extra
template widely used just about everywhere). Finally, we mostly use gcc
which has __null anyhow, so we should be able to catch any problems due to
incorrect use of NULL/nullptr anyhow.

 Regards,
VZ