From: Jeff Garland (azswdude_at_[hidden])
Date: 2020-03-24 18:32:21
On Tue, Mar 24, 2020 at 11:01 AM Mike via Boost <boost_at_[hidden]>
> 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
> 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
> Thats just a waste of time.
> Either deprecate c++03 for the whole library or not at all.
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
> 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?
The suppression macro would need to go into the header, but it wouldn't
solve the issue for a lexical_cast user.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk