[boost] nullptr vs 0

[Peter Dimov via Boost]

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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Glen Fernandes via Boost]

On Sat, May 21, 2022 at 8:59 PM Peter Dimov 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.
>

> 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.

Sounds good to me.

Glen

[Andrey Semashev via Boost]

On May 22, 2022 3:59:33 AM Peter Dimov via Boost <bo...@lists.boost.org> 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.

I'd replace 0 with NULL. If the compiler keeps complaining report a
compiler bug and suppress the warning with a pragma.

[Peter Dimov via Boost]

Andrey Semashev wrote:
> On May 22, 2022 3:59:33 AM Peter Dimov via Boost <bo...@lists.boost.org>
> 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.
>
> I'd replace 0 with NULL. If the compiler keeps complaining report a compiler
> bug and suppress the warning with a pragma.

No thanks.

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.

[Peter Dimov via Boost]

> 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.

[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.

[Bo Persson via Boost]

This happens when you write the code for C++03, but compile it for C++20.

I think it is pretty nice of the compiler to hint that things have
changed in the last 20 years.

[Christian Mazakas via Boost]

> The use of NULL as a null pointer is perfectly valid, in the sense of
both
> formal C++ compliance and code readability.

In spirit, I wholeheartedly agree with this.

Unfortunately, this issue seems to come from a perfect storm of elements.
We've
had to solve something like this for Unordered as well.

https://github.com/boostorg/unordered/issues/39

It seems to be users including Boost as a non-system header and also using
`-Wzero-as-null-pointer-constant` with clang. We don't control how users
ultimately choose to add Boost to their projects and it should be a goal to
remove any warnings we generate in their builds, within reason.

In this case, using a simple macro `BOOST_NULLPTR` is easy and
straight-forward
for both maintainers and potential contributors.
- Christian

[Richard via Boost]

In article <076301d86d77$2c794330$856bc990$@gmail.com>,

Peter Dimov via Boost <bo...@lists.boost.org> writes:

> 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.

I couldn't reproduce with clang or gcc. Do you have a repro on
compiler explorer?

This was my attempt: <https://godbolt.org/z/E3f3xnEhM>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

[Peter Dimov via Boost]

Richard wrote:
> In article <076301d86d77$2c794330$856bc990$@gmail.com>,
> Peter Dimov via Boost <bo...@lists.boost.org> writes:
>
> > 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.
>
> I couldn't reproduce with clang or gcc. Do you have a repro on compiler
> explorer?

You need -Wzero-as-null-pointer-constant which isn't on by default and is
not included in either -Wall or -Wextra.

[Ion Gaztañaga via Boost]

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 ;-)

Best,

Ion

[Peter Dimov via Boost]

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.

[Ion Gaztañaga via Boost]

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

[Peter Dimov via Boost]

Ion Gaztañaga wrote:
> 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?

But it's not possible to use boost::nullptr in portable code, because nullptr is
a keyword.

[Ion Gaztañaga via Boost]

On 24/05/2022 0:57, Peter Dimov via Boost wrote:
> Ion Gaztañaga wrote:
>> 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?
>
> But it's not possible to use boost::nullptr in portable code, because nullptr is
> a keyword.

Then BOOST_NULLPTR or boostnullptr macros are the only choice ;-)

Ion

[Andrzej Krzemienski via Boost]

niedz., 22 maj 2022 o 23:59 Andrey Semashev via Boost <bo...@lists.boost.org>
napisał(a):

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/76ff82d1912901f188599acea09cdcdb232353bd

As an application developer, I would never use BOOST_NULLPTR.

Regards,
&rzej;

[Emil Dotchevski via Boost]

On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost <
bo...@lists.boost.org> wrote:
> I'd replace 0 with NULL. If the compiler keeps complaining report a
> compiler bug and suppress the warning with a pragma.

I'm all for disabling useless warnings, but then you can leave 0 in the
code and not bother with NULL. What are you, a C programmer? :)

The whole point of BOOST_NULLPTR is to not have to deal with the useless
warning. Under that assumption, I don't see an alternative.

[Andrey Semashev via Boost]

On 5/27/22 05:14, Emil Dotchevski via Boost wrote:
> On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost <
> bo...@lists.boost.org> wrote:
>> I'd replace 0 with NULL. If the compiler keeps complaining report a
>> compiler bug and suppress the warning with a pragma.
>
> I'm all for disabling useless warnings, but then you can leave 0 in the
> code and not bother with NULL. What are you, a C programmer? :)

It *is* a useless warning. The code with NULL is explicit enough and
portable, so what is this warning about? That the code is not
C++11-only? I know that, and it's not up to the compiler to tell me that.

[Mateusz Loskot via Boost]

On Fri, 27 May 2022 at 13:01, Andrey Semashev via Boost wrote:
> On 5/27/22 05:14, Emil Dotchevski via Boost wrote:

> > On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost wrote:
> >> I'd replace 0 with NULL. If the compiler keeps complaining report a
> >> compiler bug and suppress the warning with a pragma.
> >
> > I'm all for disabling useless warnings, but then you can leave 0 in the
> > code and not bother with NULL. What are you, a C programmer? :)
>
> It *is* a useless warning. The code with NULL is explicit enough and
> portable, so what is this warning about? That the code is not
> C++11-only? I know that, and it's not up to the compiler to tell me that.

Even if you compile with -std=c++11 ?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

[Emil Dotchevski via Boost]

On Fri, May 27, 2022 at 4:02 AM Andrey Semashev via Boost <

bo...@lists.boost.org> wrote:

> On 5/27/22 05:14, Emil Dotchevski via Boost wrote:
> > On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost <
> > bo...@lists.boost.org> wrote:
> >> I'd replace 0 with NULL. If the compiler keeps complaining report a
> >> compiler bug and suppress the warning with a pragma.
> >
> > I'm all for disabling useless warnings, but then you can leave 0 in the
> > code and not bother with NULL. What are you, a C programmer? :)
>
> It *is* a useless warning. The code with NULL is explicit enough and
> portable, so what is this warning about? That the code is not
> C++11-only? I know that, and it's not up to the compiler to tell me that.
>

I wasn't being sarcastic, the warning is useless, yet if the motivation is
to work around it (and it is), there's no alternative to BOOST_NULLPTR.

We will never get compilers to be more reasonable with useless warnings
because there is zero demand for fewer warnings, and a lot of pressure on
us library developers to "fix" all warnings.

[Andrey Semashev via Boost]

On 5/27/22 16:18, Mateusz Loskot via Boost wrote:
> On Fri, 27 May 2022 at 13:01, Andrey Semashev via Boost wrote:
>> On 5/27/22 05:14, Emil Dotchevski via Boost wrote:
>>> On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost wrote:
>>>> I'd replace 0 with NULL. If the compiler keeps complaining report a
>>>> compiler bug and suppress the warning with a pragma.
>>>
>>> I'm all for disabling useless warnings, but then you can leave 0 in the
>>> code and not bother with NULL. What are you, a C programmer? :)
>>
>> It *is* a useless warning. The code with NULL is explicit enough and
>> portable, so what is this warning about? That the code is not
>> C++11-only? I know that, and it's not up to the compiler to tell me that.
>
> Even if you compile with -std=c++11 ?

Yes. Because you may be including third-party code that is
C++03-compatible. Or C. Which is not at all uncommon.

I seriously don't understand this strive to pull the world into C++XY
and set the rest on fire. Newer C++ versions extend your toolbox and
make your life easier (in most cases), and that is great and very
useful. But the fact that you can enable newer C++ version in your
compiler doesn't render the code that was written before it invalid or
bad or somehow else second-grade. Written code doesn't rewrite itself,
especially when that code works and reads perfectly well.

Personally, the main project I'm working on outside Boost is C++17. But
this project uses a lot of third-party libraries written in C and C++,
some of them C++03, with NULL, auto_ptr and other remnants of the old in
public headers. And I'm really pissed by compilers when they litter
output with warnings about stuff being deprecated or "bad style"
according to whatever guide is popular today among compiler vendors,
while the code in question actually works as expected. And how am I
supposed to act on these warnings? Do I have to rewrite the working
libraries according to the new style, retest everything, push the
changes upstream? What if the upstream project is still interested in
legacy systems that only have access to C++03? Is the amount of effort
it would take even considered when these warnings are implemented?

So my opinion is this: If you can use C++11 or newer and there are
tangible benefits to it - you are very welcome to do so. But don't force
the world to do the same. This goes for Boost and beyond. And warnings
about "bad style" are only useful to purists who want their code base
"pure C++11" for whatever imaginary reason; they are useless at best and
harmful at worst for all normal people.

[Emil Dotchevski via Boost]

On Fri, May 27, 2022 at 8:32 AM Andrey Semashev via Boost <
bo...@lists.boost.org> wrote:
> And how am I
> supposed to act on these warnings? Do I have to rewrite the working
> libraries according to the new style, retest everything, push the
> changes upstream?

This reasoning is correct for most warnings. The worst are warnings about
unsafe implicit conversions which get "fixed" by changing the semantics of
a correct program, by introducing an explicit cast. A better fix would be
to disable the warning in that specific spot, but there's zero demand for
compilers to make it easier to disable warnings.

So I sympathize with your position, but this war is unwinnable.

[Rainer Deyke via Boost]

On 27.05.22 13:00, Andrey Semashev via Boost wrote:
> It *is* a useless warning. The code with NULL is explicit enough and
> portable, so what is this warning about? That the code is not
> C++11-only? I know that, and it's not up to the compiler to tell me that.

This is not a case of the compiler, on its own initiative, warning you
about the code. This is a case of the end user explicitly telling the
compiler to warn about the code, and the compiler complying with the end
user's wishes. As I understand it, this warning is not included under
-Wall or -Wextra, so it needs to be enabled individually.

I wish there were a good way to tell the compiler to limit warning to
user code and to turn them all off in libraries. If the end user wants
to enforce the use of nullptr in their code, let them, but don't let
them force that choice onto library authors.


--
Rainer Deyke (rai...@eldwood.com)

[Soronel Haetir via Boost]

MSVC in fact has such an ability, through #pragma warning. I've no
idea if gcc or clang have anything analogous.

--
Soronel Haetir
soronel...@gmail.com

[Mateusz Loskot via Boost]

On Fri, 27 May 2022 at 17:31, Andrey Semashev via Boost wrote:
> On 5/27/22 16:18, Mateusz Loskot via Boost wrote:
> > On Fri, 27 May 2022 at 13:01, Andrey Semashev via Boost wrote:
> >> On 5/27/22 05:14, Emil Dotchevski via Boost wrote:
> >>> On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost wrote:
> >>>> I'd replace 0 with NULL. If the compiler keeps complaining report a
> >>>> compiler bug and suppress the warning with a pragma.
> >>>
> >>> I'm all for disabling useless warnings, but then you can leave 0 in the
> >>> code and not bother with NULL. What are you, a C programmer? :)
> >>
> >> It *is* a useless warning. The code with NULL is explicit enough and
> >> portable, so what is this warning about? That the code is not
> >> C++11-only? I know that, and it's not up to the compiler to tell me that.
> >
> > Even if you compile with -std=c++11 ?
>
> Yes. Because you may be including third-party code that is
> C++03-compatible. Or C. Which is not at all uncommon.

> [...]

Yes, that is often the case. Still, I don't mind receiving the warning,
because it gives me feedback on C++ state of my dependencies
which is useful for variety of reasons (internal policies and conventions).

> Personally, the main project I'm working on outside Boost is C++17. But
> this project uses a lot of third-party libraries written in C and C++,
> some of them C++03, with NULL, auto_ptr and other remnants of the old in
> public headers. And I'm really pissed by compilers when they litter
> output with warnings about stuff being deprecated or "bad style"
> according to whatever guide is popular today among compiler vendors,
> while the code in question actually works as expected. And how am I
> supposed to act on these warnings?

Yes, that is annoying.
I use my proxy headers and sling pragmas to disable them.

> Do I have to rewrite the working libraries according to the new style,
> retest everything, push the changes upstream?
> What if the upstream project is still interested in
> legacy systems that only have access to C++03? Is the amount of effort
> it would take even considered when these warnings are implemented?

I ask those questions myself too and I often end up discussing the matter
with maintainers of my third-parties, and I try to contribute with any
modernisation, if that is sensible and acceptable.

> So my opinion is this: If you can use C++11 or newer and there are
> tangible benefits to it - you are very welcome to do so. But don't force
> the world to do the same.

That is not what I aim or mean.
I just was curious why a compiler feature I consider useful
you seem to consider a bug :-)

Thanks for the explanation.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

[Soronel Haetir via Boost]

Something I would consider useful from a compiler standpoint would be
able to control warnings on a path basis. That is, if it's part of the
system includes (along with other customizable directories), a
different, much more forgiving set of warnings is in effect.
Particularly for style warnings like NULL vs nullptr vs 0. Only code
that is explicitly part of my current target (whatever that means in
the given environment) should have stylistic warnings in effect.

Even MSVC's #pragma warning doesn't give that kind of control, it can
reduce warnings (or disable particular warnings) for a block of
includes, but has nothing to do with the paths the files come from.

--
Soronel Haetir
soronel...@gmail.com

[Peter Dimov via Boost]

Soronel Haetir wrote:
> Something I would consider useful from a compiler standpoint would be able
> to control warnings on a path basis. That is, if it's part of the system includes
> (along with other customizable directories), a different, much more forgiving
> set of warnings is in effect.
> Particularly for style warnings like NULL vs nullptr vs 0. Only code that is
> explicitly part of my current target (whatever that means in the given
> environment) should have stylistic warnings in effect.
>
> Even MSVC's #pragma warning doesn't give that kind of control, it can reduce
> warnings (or disable particular warnings) for a block of includes, but has
> nothing to do with the paths the files come from.

That's not as useful as it seems because the header is often included multiple
times using different paths and because of include guards only the first path
matters, which usually has nothing to do with the path that would have led
to the warning were those previous includes not present.

[Andrey Semashev via Boost]

On 5/28/22 20:21, Peter Dimov via Boost wrote:
> Soronel Haetir wrote:
>> Something I would consider useful from a compiler standpoint would be able
>> to control warnings on a path basis. That is, if it's part of the system includes
>> (along with other customizable directories), a different, much more forgiving
>> set of warnings is in effect.
>> Particularly for style warnings like NULL vs nullptr vs 0. Only code that is
>> explicitly part of my current target (whatever that means in the given
>> environment) should have stylistic warnings in effect.
>>
>> Even MSVC's #pragma warning doesn't give that kind of control, it can reduce
>> warnings (or disable particular warnings) for a block of includes, but has
>> nothing to do with the paths the files come from.
>
> That's not as useful as it seems because the header is often included multiple
> times using different paths and because of include guards only the first path
> matters, which usually has nothing to do with the path that would have led
> to the warning were those previous includes not present.

I think the idea is to associate warning settings with a set of files in
the filesystem (i.e. inodes), not the paths to them. Somewhat similar to
how `#pragma once` works. Although there are caveats with `#pragma
once`, most of the time it works rather reliably, so maybe not such a
bad idea. Though I have a hard time to imagine how such heterogeneous
settings would be expressed.

[Andrea Bocci via Boost]

On Sat, 28 May 2022, 19:15 Soronel Haetir via Boost, <bo...@lists.boost.org>
wrote:

> Something I would consider useful from a compiler standpoint would be
> able to control warnings on a path basis. That is, if it's part of the
> system includes (along with other customizable directories), a
> different, much more forgiving set of warnings is in effect.
>

Doesn't GCC's "-isystem" do just that ?

.Andrea

[Emil Dotchevski via Boost]

On Sat, May 21, 2022 at 5:59 PM Peter Dimov via Boost <bo...@lists.boost.org>

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.

Do we have an official Boost policy on "fixing" warnings? E.g. what sort of
warnings should or should not be fixed?

[Glen Fernandes via Boost]

On Saturday, May 28, 2022, Emil Dotchevski wrote:

> On Sat, May 21, 2022 at 5:59 PM Peter Dimov

> 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.
>
> Do we have an official Boost policy on "fixing" warnings? E.g. what sort of
> warnings should or should not be fixed?

As far as I know, we don't. We require code to be well-defined and correct.
If the code is correct and well-defined, the thing motivating me to change
correct code to prevent a warning is the convenience for the user.

But only in so far as changing the code does not compromise its performance
or maintainability, etc.

BOOST_NULLPTR being added to Config isn't a mandate to all maintainers to
use it. Just a choice.

If it exists, I would use it. If it exists in Config it means I won't have
to duplicate the following lines in a handful of libraries:

if !defined(BOOST_NO_CXX11_NULLPTR)
#define BOOST_NULLPTR nullptr
#else
#define BOOST_NULLPTR 0
#endif

Unless someone comes up with an idea I find more appealing. (Which hasn't
happened yet in this thread)

Glen

[Emil Dotchevski via Boost]

On Sat, May 28, 2022 at 1:20 PM Glen Fernandes <glen.fe...@gmail.com>
wrote:

+1

[Ion Gaztañaga via Boost]

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.

Just reviewing boost/cstdint.hpp, to know where "portable" types were
defined in Boost, surprisingly that is provided by Boost.Config.
Providing portable nullptr-like type/macro sounds pretty similar to me.

My 2 cents,

Ion

[Gavin Lambert via Boost]

On 29/05/2022 05:39, Andrea Bocci wrote:

> On Sat, 28 May 2022, 19:15 Soronel Haetir wrote:
>
>> Something I would consider useful from a compiler standpoint would be
>> able to control warnings on a path basis. That is, if it's part of the
>> system includes (along with other customizable directories), a
>> different, much more forgiving set of warnings is in effect.
>
> Doesn't GCC's "-isystem" do just that ?

It does, but MSVC lacks an equivalent; and both are not entirely
consistent about warnings arising from templates that are defined in a
system path but then only instantiated later as a result of user code.

Also, that disables all warnings, which can sometimes be too large a
hammer to wield.

[Gavin Lambert via Boost]

On 27/05/2022 23:00, Andrey Semashev wrote:
> It *is* a useless warning. The code with NULL is explicit enough and
> portable, so what is this warning about? That the code is not
> C++11-only? I know that, and it's not up to the compiler to tell me that.

The problem is that NULL is defined as a plain 0, and there is potential
ambiguity with comparing a pointer to 0 -- did you actually intend to
compare the pointer itself or were you intending to compare the value
being pointed to? This is obvious when compared to anything other than
0, but 0 gets this special magic treatment due to historic precedent
(which is, as usual with C/C++, misguided other than for backwards
compatibility).

It's actually worse in C++, because C defines NULL as explicitly
pointer-typed, but C++ doesn't (because it introduces new warnings about
comparing void pointers with other pointers) -- but this also means at
the compiler level it can't tell if you did actually write NULL or 0, so
it has even less idea whether it was intended or not. As usual,
backwards compatibility is a comedy of errors.

Strongly suggesting (but not requiring) that all newly-written code
should use nullptr rather than NULL or 0 is the correct choice. The
only reason you might not do so is for C++03 compatibility -- but newly
written code really shouldn't be trying to do that either any more. The
language has moved on, and codebases should too.

I support use of BOOST_NULLPTR for compatibility of old codebases, however.

[Andrey Semashev via Boost]

On 5/30/22 02:22, Gavin Lambert via Boost wrote:
> On 27/05/2022 23:00, Andrey Semashev wrote:
>> It *is* a useless warning. The code with NULL is explicit enough and
>> portable, so what is this warning about? That the code is not
>> C++11-only? I know that, and it's not up to the compiler to tell me that.
>

> The problem is that NULL is defined as a plain 0...

This is an implementation detail. It could be __builtin_null(), which
would behave equivalent to 0 or (void*)0 but would not emit warnings.

[Emil Dotchevski via Boost]

On Sun, May 29, 2022 at 4:39 PM Andrey Semashev via Boost <
bo...@lists.boost.org> wrote:
>
> On 5/30/22 02:22, Gavin Lambert via Boost wrote:
> > On 27/05/2022 23:00, Andrey Semashev wrote:
> >> It *is* a useless warning. The code with NULL is explicit enough and
> >> portable, so what is this warning about? That the code is not
> >> C++11-only? I know that, and it's not up to the compiler to tell me
that.
> >
> > The problem is that NULL is defined as a plain 0...
>
> This is an implementation detail. It could be __builtin_null(), which
> would behave equivalent to 0 or (void*)0 but would not emit warnings.

In C++ it is not allowed for NULL to be of type void* (it is allowed in C).

It could be some __null thing, but it has to behave the same as 0, except
maybe generate appropriate warnings. I've seen NULL defined as 0 or 0L,
which means overload resolution and thus portability is affected. Best to
avoid it in C++.

[Peter Dimov via Boost]

Emil Dotchevski wrote:
> In C++ it is not allowed for NULL to be of type void* (it is allowed in C).
>
> It could be some __null thing, but it has to behave the same as 0, except
> maybe generate appropriate warnings.

That's exactly what it is under GCC.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/support.html#std.support.types.null

[Tom Honermann via Boost]

On 5/29/22 6:56 PM, Gavin Lambert via Boost wrote:
> On 29/05/2022 05:39, Andrea Bocci wrote:
>> On Sat, 28 May 2022, 19:15 Soronel Haetir wrote:
>>
>>> Something I would consider useful from a compiler standpoint would be
>>> able to control warnings on a path basis. That is, if it's part of the
>>> system includes (along with other customizable directories), a
>>> different, much more forgiving set of warnings is in effect.
>>
>> Doesn't GCC's "-isystem" do just that ?
>
> It does, but MSVC lacks an equivalent;

Recent MSVC releases now have similar capabilities. See the /external
<https://docs.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-170>
option.

Tom.