Re: [PATCH] use nullptr more?

On 01/20/2014 02:28 PM, Amos Jeffries wrote:
> 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:

The above actually sounds like a reason _not_ to redefine NULL to me:

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

And now we are saying, "Take that International Standard! We are going
to use what we think is the right NULL, and there is nothing you can do
about it!"

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

I do not see how redefining NULL (on top of the above mess) would
necessarily be better than leaving it alone. Are we trying to fix cases
where different 3rd-party headers #define NULL differently?

For the record, I am not objecting to this change. It would be great to
understand why it is being done, but if others are sure it is needed,
you do not need to convince me.

Thank you,

Alex.
Received on Mon Jan 20 2014 - 23:47:49 MST