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
