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
