boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?
In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue? ../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98-...
On 24/03/2020 13:58, Jeff Garland via Boost wrote:
Well it will be a real issue in a year from now when we being removing C++03 support - it may be that lexical_cast's dependencies have nothing that will actually break (but I would need to check that), or that as a temporary measure we could continue to support C++03 in selected sub-parts if there is real demand for it. Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ? John.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, 24 Mar 2020 at 10:26, John Maddock via Boost <boost@lists.boost.org> wrote:
Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ?
clang-10 is final soon. It's only relevant on linux (clang-cl only sort of works from 3.8 and upwards and IOS does its own thing anyway) and how many have 3.4 as the default? degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
it's basically using it for floating point traits and functions like changesign. lexical_cast/detail/if_nan.hpp #include <boost/math/special_functions/sign.hpp> #include <boost/math/special_functions/fpclassify.hpp>
Question: will anyone care about clang-3.4 a year from now given that we're currently on clang-9 ?
I'd be fine if the answer is to drop really old compilers -- who makes that decision these days, the steering committee?
On 24/03/2020 17:32, Jeff Garland via Boost wrote:
Not sure, but there was a message thread a while back to the effect that dropping C++03 support was OK as long as there was 12 months of deprecation first. John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, Mar 24, 2020 at 10:42 AM John Maddock via Boost < boost@lists.boost.org> wrote:
It would be nice if it's not a big deal to do, as I expect lexical cast will continue to support c++03. And the warnings show up in date-time, icl and probably other libraries that have lexical cast -- or include date-time. But really, only if it's simple to do. Not sure, but there was a message thread a while back to the effect that
dropping C++03 support was OK as long as there was 12 months of deprecation first.
Which seems entirely reasonable given that 03 is really 98 so we are talking about 20 years... Jeff
There was talk / the suggestion to move some core parts to a separate library, also to avoid circular dependencies: https://github.com/boostorg/math/issues/151 That would also solve this problem as a side effect.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Can't speak for John, but personally I think that deciding for each header individually whether it might use c++11 features in a year doesn't make sense. In turn that would mean that everytime you want to use a c++11 feature in a header that didn't use one before, you need to wait for another year and you have to be super careful about which header includes which other header. Thats just a waste of time. Either deprecate c++03 for the whole library or not at all. That aside, what is the harm in simply defining the supression macro when compiling your tests with older compilers? I think the bigger question is: Will date_time continue to support c++03 when (some) of the libraries it currently depends on don't?
As degski mentioned, I doubt clang 3.4 was a particularly popular compiler to begin with, so the answer is probably no. Two suggestions: 1) As c++11 support is not a yes/no thing, could you perhaps specify which compiler versions you plan to support? E.g. gcc 4.8 was/is a pretty popular c++11 compiler but had a lot of conformance issues and libstdc++ was still missing a lot of things. So while probably no one cares about clang-3.4, gcc 4.8 support might be important. As always, not supporting X wouldn't mean it won't work, just that you might not test it and might not invest time to fix compatibility problems. 2) If I understand this correctly, c++03 support is just now going to be deprecated. Maybe this should not yet generate compile-time warnings as soon as a header is included but for now only during compilation of boost math sources, examples and unit tests themselves. The general warning could then be added in the next release. Of course in addtion to announcements here on the ML, in the release notes, the docs and maybe on reddit, twitter and/or slack. Best Mike
On Tue, 24 Mar 2020 at 12:18, Peter Dimov via Boost <boost@lists.boost.org> wrote:
And then there was Xenial and there after Bionic, and judging from the past release dates soon a new LTS release. In the meanwhile IBM acquired RedHat (and Fedora and CentOS) ... degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
clang-10 just got released, so soon, was really soon. degski On Tue, 24 Mar 2020 at 13:00, Peter Dimov via Boost <boost@lists.boost.org> wrote:
-- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
On 08/04/2020 15:11, Jeff Garland via Boost wrote:
So it looks like a change in math got pushed to develop that fixed this up, thank you. Are we pushing it to master for 1.73?
I believe I already have, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, Mar 24, 2020 at 11:01 AM Mike via Boost <boost@lists.boost.org> wrote:
Boost libraries jump thru a tremendous number of hoops -- see the macro list in boost.config. For many things it's not to bad to support different configurations, although that's increasingly difficult. Obviously something in math makes them ready to move on from 03, but probably not for the functions here. John, who is responsible in part for config will certainly know. I guess the odd part for me is gcc and other clang compilers in 98 mode don't have the warning -- so there must be something unique about 3.x. And sure, I might jump on the band wagon to dump support for 98/03 in some future release. And, overall I'd like to reduce those dependencies anyway and newer standard libraries have facilities to help on that. That aside, what is the harm in simply defining the supression macro when
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.
Jeff Garland wrote:
The suppression macro would need to go into the header, but it wouldn't solve the issue for a lexical_cast user.
The issue for the lexical_cast user is that his code will break when Math drops C++03 support, and the whole point of the message is to communicate this. The message is supposed to be verbose and annoying, because otherwise nobody will pay any attention to it. Sure, the user has no immediate recourse; he can only apply pressure on the lexical_cast maintainers to deal with it somehow. But again, if there's no message, nobody will care.
On 24/03/2020 19:06, Peter Dimov via Boost wrote:
Haha, yes, that's basically why I made it so... annoying. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Tue, Mar 24, 2020 at 12:19 PM John Maddock via Boost < boost@lists.boost.org> wrote:
Although I think we've determined that the functions involved won't be impacted -- so we're warning about a future non-event. Perhaps turning off the warning in lexical_cast is the correct option for 1.73 with a refactor (probably of math functions to core) for 1.74.
Jeff
On Tue, 24 Mar 2020 at 13:06, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Another option would be to keep supporting boost::lexical_cast '03 for a while, and move to Boost.Spirit, which is miles better anyway. Then while at it, additionally adopt <charconv>. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
Not sure if that would be a good idea. Even if you are sure that your headers will still compile in c++03 in a year (either because they no longer include boost math headers at all - neither directly nor indirectly - or the specific headers remain compatible with 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. Best Mike
On Tue, Mar 24, 2020 at 1:46 PM Mike via Boost <boost@lists.boost.org> wrote:
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.
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.
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
participants (5)
-
degski -
Jeff Garland -
John Maddock -
Mike -
Peter Dimov