Re: [PATCH] use nullptr more?

On 2014-01-21 08:05, Alex Rousskov wrote:
> On 01/20/2014 08:15 AM, Kinkie wrote:
>
>> the attached patch is an attempt (build-tested) to rely more on
>> nullptr in place of NULL.
>> It takes from the current implementation, it is just a bit more
>> forceful in using nullptr if available.
>
> Hi Kinkie,
>
> You forgot to mention *why* do we want to overwrite the external
> NULL definition? Overwriting NULL set by others will prevent folks with
> broken compilers working around nullptr compatibility issues. What will
> it give us in return, the ability to overwrite NULL #defined in some
> header we happened to #include?
>

The only reason I know of that we might want to is that cstd* headers
define NULL explicitly now, whereas before C++11 it was optionally
there:

"
   C.3.2.4 Macro NULL [diff.null]

   1/ The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>,
<cstdlib>, <cstring>, <ctime>, or <cwchar>, is an implementation-defined
C++ null pointer constant in this International Standard (18.2).
"

Strictly following the libcompat intentions we should have defined
nullptr_t when it was missing and replaced all uses of NULL across the
code. I chose not to go with that after following the standards
committee discussion on why they did not standardize the name "NULL".
They identified a minefield of backward compatibility issues with the
above mentioned custom definitions, all sorts of strange definitions for
NULL exist [eg. #define NULL ((void*)((WIDE)(0x0C 0x0D))) was the
nastiest one I've seen] and people using it to define all sorts of
object types to an assumed OS-specific value.

Amos
Received on Mon Jan 20 2014 - 21:29:03 MST