Paul Eggert wrote:
> > +# ifdef __cplusplus
> > +/* For the C++ compiler the result of the configure test is irrelevant.
> > + We know that at least g++ and clang with option -std=c++11 or higher,
> > as well
> > + as MSVC 14 or newer, already have nullptr. */
> > +# if !(((defined __GNUC__ || defined __clang__) && __cplusplus >=
> > 201103L) \
> > + || (defined _MSC_VER && 1900 <= _MSC_VER))
>
> <https://en.cppreference.com/w/cpp/language/nullptr> says nullptr is
> part of C++11, so would it be better to omit the "(defined __GNUC__ ||
> defined __clang__) && "? It seems unlikely that a compiler would
> advertise conformance to C++11 without supporting nullptr.
Unlikely?! You must be joking. We have seen so many occurrences where
compilers define __STDC_VERSION__ to a certain value without implementing
the corresponding standard entirely and correctly. Why should it be different
with __cplusplus? It is a common human behaviour to claim "we have XYZ!"
when in fact they only have 90% of XYZ.
In this particular case,
- if we leave 'nullptr' alone although the compiler doesn't support it,
there will be a compilation error quickly,
- if we define 'nullptr' although the compiler supports it already, there
are good chances that there will be no compilation error. (That's what
I observed with all compilers except GCC.)
Therefore I did not want to make bets regarding C++ compilers that set
__cplusplus = 201103L but that I have not tested.
Bruno
