Re: [PATCH] use nullptr more?

On Tue, Jan 21, 2014 at 2:31 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> 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.

Now now.. My aim was (and is) not to induce controversy.
The main benefit of nullptr lays in the fact that it is of type
nullptr_t, which is implicitly convertible and comparable to any
pointer type or pointer-to-member type. It is not implicitly
convertible or comparable to integral types, except for bool.
(copypasted from stackoverflow).

So in theory the change I did should NOT change any visible behavior,
but help catch unwanted pointer arithmetic, implicit type cast to int,
truncation issues caused by casts to int etc.
Total effort needed to verify if this causes unforeseen problem is 3
hours of farm build time.
Is it clean? Probably not. Does it work? Maybe. Does it help?
Possibly. Any issues this causes are at compile time and easily
detectable.
I won't push for this to go in. If you aren't convinced, we can
certainly keep on going like we have so far, and it will keep on
working like it does now.

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

Hopefully.

-- 
    /kinkie