Ich muss nullptr zu einer Cross-Plattform-Bibliothek zurückportieren, die wir haben, aber ich habe Probleme, eine zuverlässige Überprüfung der Unterstützung von nullptr zu bekommen.
Zunächst hatte ich das:
%Vor%Aber dann entdeckte ich, dass das Kompilieren eines Programms, das nur den Wert von __cplusplus ausgab, unerwartete Ergebnisse hervorbrachte.
Ein Blogpost behauptete 199711L war ein Wert, den MS-Compiler verwenden, um teilweise Unterstützung für C ++ 11 anzuzeigen. Aber ich stelle fest, dass g ++ 5.4 diesen Wert standardmäßig erzeugt. Bis Sie ihm ausdrücklich mitteilen, dass er mit -std = c ++ 11 kompilieren soll. Aber wenn Sie dann sagen, dass der Standard c ++ 98 ist, wird der Wert 199711 immer noch angezeigt. Das klingt nicht richtig für mich. Das ist also kein guter Check!
Dann sah ich jemanden, der das macht mit einer Antwort, die behauptet, es könnte funktionieren. Nun, das tut es nicht.
%Vor%Aber ich bin mir nicht sicher, dass Sie das tun können. Also habe ich es so getestet:
%Vor%Was? Der Fehler wird nicht ausgegeben, wenn nullptr tatsächlich verfügbar ist. So ist das überhaupt nicht.
Wie erkenne ich nullptr oder Compiler-Version unter Linux / Windows und OSX (Clang) / Android.
Wenn Sie Boost verwenden, Boost.Config bietet das Makro BOOST_NO_CXX11_NULLPTR .
Boost implementiert dies, indem es es für jedes Compiler-Version-Combo definiert, das es nicht unterstützt, so dass Sie die Funktionalität nicht einfach duplizieren können.
Wenn Sie CMake verwenden, können Sie den Compiler verwenden Feature-Erkennung (speziell cxx_nullptr ), um ein Makro bedingt zu definieren.
#if !defined(nullptr) funktioniert nicht, weil nullptr kein Makro ist.