Re: boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?

From: Jeff Garland (azswdude_at_[hidden])
Date: 2020-03-24 21:32:16

On Tue, Mar 24, 2020 at 1:46 PM Mike via Boost <boost_at_[hidden]>
wrote:

> > Gesendet: Dienstag, 24. März 2020 um 19:32 Uhr
> > Von: "Jeff Garland via Boost" <boost_at_[hidden]>
> >
> >
> > The suppression macro would need to go into the header
>
> Not sure if that would be a good idea.
>

I'm not a fan of the approach either -- hence the email thread.

Even if you are sure that your headers will still compile in c++03 in a
> year
>

And again, to be clear, they compile cleanly on clang4+ and all variants of
gcc now bc the boost math warning is only relevant to clang3.x.

> (either because they no longer include boost math headers at all - neither
> directly
> nor indirectly - or the specific headers remain compatible with 03).
>

The irony here is that, if anything, I'd keep lexical_cast for 03
compatibility and use to_string or charconv to break the dependency on
lexical_cast.  Of course, those require facilities not in 03.

> That macro will leak and suppress the warning along different include
> chainis,
> where the authors might not make give any such guarantees.
>

> Of course you could define and later restore the macro, but personally I
> think
> such suppression macros really belong on the command line of whoever is
> assembling the final binary.
>
> Yep, but keep in mind that if you're using 1.73 boost with clang3.x you'll
have to actively suppress a warning about something that is a 'future
problem' -- that isn't really an issue with your code in any way.  It's
simply a decision, ultimately, that boost authors have made that is
annoying. I mean we could have a warning like "dropping support for
clang3.x after this release for the following libraries' which would be far
more informative and actionable from the user point of view.  I feel we can
come up with a better path than having this warning.

Jeff