On 23/05/2022 22:06, Peter Dimov via Boost wrote:
Ion Gaztañaga wrote:
On 22/05/2022 2:59, Peter Dimov via Boost wrote:
Compilers apparently are warning on the use of 0 as a null pointer constant, suggesting we use nullptr instead. But compilers don't know that we support C++03 where nullptr isn't a thing.
Case in point: https://github.com/boostorg/throw_exception/pull/22
ifdef-ing every use of nullptr is unwieldy, so maybe we need BOOST_NULLPTR added to Boost.Config? That would expand to nullptr when it's supported, and 0 otherwise.
Maybe we need the boost::nullptr_t type, emulated in C++ mode and "typedef decltype(nullptr) nullptr_t;" in compilers that support it...
And if nullptr/nullptr_t is provided by Boost.Config, without any heavy-include need, that would be perfect ;-)
That's not what Boost.Config is for.
Plus, since nullptr is a keyword, available without qualification in any scope, it wouldn't be possible for us to provide a compatible replacement as we aren't allowed to define things in the global namespace.
For our purposes it will probably work most of the time if defined in boost:: but there's no good way to define a global in a header under C++03 anyway.
Well, I wasn't "literally" trying to define nullptr[_t], but a practical alternative that is the same type as the standard one when available. BOOST_NULLPTR/boost::nullptr and boost::nullptr_t are more than enough for portable code. Does it make sense? Ion