niedz., 22 maj 2022 o 23:59 Andrey Semashev via Boost
On 5/22/22 18:35, Peter Dimov wrote:
I did however not know that GCC doesn't warn on NULL. Interesting compromise, even though I don't quite see the point of it.
Clang does warn on NULL, however.
I do see the point of it now. Under GCC the warning is pragmatically intended to catch actual mistakes such as mistyping
while( *p != 0 )
as
while( p != 0 )
so the warning only triggers on the actual 0, and is enabled under C++03 as well.
Clang, and the various static analysis tools such as the MS analyzer, enforce a stylistic preference for nullptr, so they warn on both 0 and NULL, but Clang doesn't warn in C++03 mode.
Either way, I'm not looking forward to adding a bunch of lines to suppress the various warnings, instead of just telling the PR author to use BOOST_NULLPTR instead of nullptr.
We already have NULL as the portable macro, so I would still prefer it to a Boost invention.
Again, that some compilers warn on NULL is a compiler bug and should be treated as such, IMO. Compiler vendors should keep their stylistic preferences to themselves, especially when they are impossible to follow (in C++03 case). The use of NULL as a null pointer is perfectly valid, in the sense of both formal C++ compliance and code readability.
While I agree with the above argument, I still support the idea of adding BOOST_NULLPTR to Boost.Config. My reasoning is that the macro is meant to be used by library implementers; and the world of library implementers is different from the world of application developers, who consume the libraries. As a regular application developer, I know which version of C++ I am using, and I know if I should use NULL or nullptr. I also know which compiler warning to turn off. In contrast, Boost is known to have served as a "platform" that screens the users from compiler differences and compiler bugs. To say "file a bug against the compiler and have Boost just use NULL" goes against this tradition. As a maintainer of a library that supports C++98 compilers with bugs, I feel compelled to use something like BOOST_NULLPTR. In fact, I have been hit by this very issue: https://github.com/boostorg/optional/commit/76ff82d1912901f188599acea09cdcdb... As an application developer, I would never use BOOST_NULLPTR. Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost