Now using nullptr in the headers, if it is supported by the compiler

[bibo38]

Since Clang 5, it can warn about the usage of 0/NULL instead of nullptr. This caused me to include some ugly workaround in the Cuberite project.

To fix this problem at the root, I've used CMake to generate an appropriate includefile, which checks if nullptr is supported. Based on this check the macro COMPABILITY_NULLPTR is either set to nullptr or 0.

[coveralls]

Coverage remained the same at 96.344% when pulling 62347c2 on bibo38:fix_nullptr into 3f3b174 on SRombauts:master.

[coveralls]

Coverage remained the same at 96.344% when pulling 2a0d13d on bibo38:fix_nullptr into 3f3b174 on SRombauts:master.

[bibo38]

Since CMake 3.2 defined the macro as static_cast<void*>(0) and didn't recognized the Apple Clang compiler, I've just added the generated file with CMake 3.9 to the project.

The alternative would be to require at least CMake 3.8. This version adds a flag to prevent erros, if the compiler cannot be detected.

P.S.: Travis failed due some apt-get problem...

[SRombauts]

Hi @bibo38, thank you very much for the time you took to propose this!

I was hesitant to use such a (quite complexe) CMake solution...

So I was about to simply use "nullptr" and drop support for older compilers, but I decided to rely instead on one of my old "Utils.h" file from my SRombauts/LoggerCpp projet.
This Utils.h redefine nullptr_t if possible, or rely on the older NULL macro on older MSVC.

See commit 4f32da1

Cheesr!