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 10:54:13 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-10-26 0:48 UTC, Vadim Zeitlin wrote:
> On Thu, 26 Oct 2006 00:36:20 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> [...] 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.

Resolution: For now, 'NULL' is preferable. If you see a '0'
in old code that means 'NULL' and want to change it, feel free.
Sometime in the future, I may consider using 'nullptr' instead,
with the "library implementation":

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

but only after investigating issues such as:

>  IMO this is over-engineering. As indicated in the paper, using such
> implementation would result in very unclear error messages

As does 'BOOST_STATIC_ASSERT'. Templates in general have this
problem. I don't give this consideration a lot of weight when
deciding whether to use a class with member templates. I'd
give much more weight to your next point:

> and, another
> practical consideration, it could also increase compile time (an extra
> template widely used just about everywhere).

This is measurable. It'd be wrong to use this class generally
without measuring it first.

It may conceivably make sense to use it conditionally, say,
under the same circumstances as '_GLIBCXX_CONCEPT_CHECKS'.

[Maybe that's a bad example, and '_GLIBCXX_CONCEPT_CHECKS'
should be used more generally now, because the overhead is
said to have been reduced:
  http://gcc.gnu.org/onlinedocs/libstdc++/19_diagnostics/howto.html
compared to the old SGI implementation. That, too, is
measurable. Someday.]

> 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.

The paper says
  "__null is a magic keyword similar to nullptr"
so I surmise that they're not quite semantically equivalent.
I don't know whether 'class nullptr' is equivalent to the
'nullptr' keyword either, though. OTOH, I don't know of a
concrete case where the "library implementation" has a
demonstrable advantage over gcc's '__null', either.




reply via email to

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