lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] Re: 'NULL' versus '0'
Date: Thu, 26 Oct 2006 00:36:20 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-10-25 13:50 UTC, Vadim Zeitlin wrote:
> On Wed, 25 Oct 2006 13:27:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> My 'style' document makes no mention of 'NULL' (yet). I've
> GC> always used '0' instead, following Stroustrup:
[...]
> GC> However, he has changed his thinking:

> gcc (which already defines NULL as __null as the same paper mentions).

I snip your discussion, which I accept as making a compelling
case for using an identifier, instead of a literal zero, to
represent a null pointer.

> GC> [...] Anything but 'NULL'....
> 
>  Could I ask why? There must be some argument against it to compensate the
> 2 strong arguments in favour of using it I gave above, mustn't it?

Reexamining my viewpoint, I realize that my dislike for 'NULL' dates
back to the nineteen-eighties, when folks argued whether its value
should be '0', '0L', or (after C89/90) '(void*)(0)'. Each of those
had problems. So, when I switched to C++, Stroustrup's pointing out
that '0' worked just fine in C++ seemed quite liberating, and I've
avoided writing 'NULL' ever since. But now that's all just ancient
history, and should guide us no longer. Thanks for helping me to
realize that.

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

If not, I would now propose changing 'config.hpp' as follows:

  #else // Not using autoconf.

+ #if defined __GNUG__
+ #   define nullptr __null
+ #else  // Compiler not known to support anything like 'nullptr'.
+ #   include <cstddef>
+ #   define nullptr NULL
+ #endif // Compiler not known to support anything like 'nullptr'.
+
  // Redundant include guards are passé: with modern tools, the benefit

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]