Re: [PATCH] use nullptr more?

On 2014-01-21 12:47, Alex Rousskov wrote:
> 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!"
>

Pretty much. Although not so much as "Take that IS!" as "Take that GCC"
since it is defined to be implementation specific. All we do with #undef
is add risk screwing up the alignment with OS code and third-party code
libraries which may now be depending on those compiler-specific defines.

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

Exactly.

It exists in its current form to fix systems where it is completely
omitted. Changing an existing definition is risky.

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

I don't think any change here is needed. The existing hack (and it is
just a hack) was a good idea at the time, and still is for all the GCC
4.0-4.5 compilers and old systems not defining it at all. But it is
becoming increasingly irrelevant and when we someday switch to requiring
a C++11 compiler NULL can be erased completely.

Amos
Received on Tue Jan 21 2014 - 01:31:46 MST