Re: nullptr vs 0

From: Soronel Haetir (soronel.haetir_at_[hidden])
Date: 2022-05-28 17:00:57

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_at_[hidden]> 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_at_[hidden]