-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Cromwell Enage via Boost Sent: 03 November 2018 02:18 To: boost@lists.boost.org Cc: Cromwell Enage Subject: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
Hi, everyone.
The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-dependencies>--the following Boost libraries known to use Boost.Parameter would also become C++11:
Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2
I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary.
My view is that it is up to you to decide (but asking for views is good too). If it is not too difficult to make it continue to be C++03 compatible and yet allow C++11 (or higher) improvements then you should do this. For example, if you can easily write #ifdef BOOST_NO_C11_feature do the current C++03 stuff (even full function definition) #else do the enhanced version #endif then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it "We should try to eliminate things that unnecessarily piss people off," (See https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n... for sordid details) but if this proves difficult (and trying it may be the only way to find out) then you should announce that it will require some C++11 feature one release ahead of the change. You should change the jamfile to require the new C++11 feature(s) as this demo https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/buil... This will leave a blank in the regression matrix for those platforms that don't support this C++11 feature that will flag to users that it won't work and they need to freeze their Boost at this version, or get a more up-to-date compiler. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830