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.
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
On May 22, 2022 3:59:33 AM Peter Dimov via Boost <boost@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.
Andrey Semashev wrote:
On May 22, 2022 3:59:33 AM Peter Dimov via Boost <boost@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.
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.
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.
On 2022-05-22 at 23:58, Andrey Semashev via Boost wrote:
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.
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.
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
niedz., 22 maj 2022 o 23:59 Andrey Semashev via Boost <boost@lists.boost.org> napisał(a):
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
On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost < boost@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.
On 5/27/22 05:14, Emil Dotchevski via Boost wrote:
On Sun, May 22, 2022 at 3:35 AM Andrey Semashev via Boost < boost@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.
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
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.
On Fri, May 27, 2022 at 8:32 AM Andrey Semashev via Boost < boost@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.
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
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. On 5/28/22, Mateusz Loskot via Boost <boost@lists.boost.org> wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Soronel Haetir soronel.haetir@gmail.com
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.
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.
On Sat, 28 May 2022, 19:15 Soronel Haetir via Boost, <boost@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
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.
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.
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, May 27, 2022 at 4:02 AM Andrey Semashev via Boost < boost@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 < boost@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.
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 (rainerd@eldwood.com)
MSVC in fact has such an ability, through #pragma warning. I've no idea if gcc or clang have anything analogous. On 5/27/22, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
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 (rainerd@eldwood.com)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Soronel Haetir soronel.haetir@gmail.com
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.
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.
On Sun, May 29, 2022 at 4:39 PM Andrey Semashev via Boost < boost@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++.
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.typ...
In article <076301d86d77$2c794330$856bc990$@gmail.com>, Peter Dimov via Boost <boost@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>
Richard wrote:
In article <076301d86d77$2c794330$856bc990$@gmail.com>, Peter Dimov via Boost <boost@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.
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
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.
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
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.
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
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
On Sat, May 21, 2022 at 5:59 PM Peter Dimov via Boost <boost@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?
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
On Sat, May 28, 2022 at 1:20 PM Glen Fernandes <glen.fernandes@gmail.com> wrote:
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
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
of 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
+1
participants (15)
-
Andrea Bocci -
Andrey Semashev -
Andrzej Krzemienski -
Bo Persson -
Christian Mazakas -
Emil Dotchevski -
Gavin Lambert -
Glen Fernandes -
Ion Gaztañaga -
Mateusz Loskot -
Peter Dimov -
Rainer Deyke -
Richard -
Soronel Haetir -
Tom Honermann