|
Boost : |
Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-06 12:14:31
On 5 Jun 2015 at 5:30, Edward Diener wrote:
> I don't know what "the right approach" would be but this is one approach
> that does work easily, following the documentation I have written about
> it and added to the Boost.config documentation.
Firstly, this is a long overdue patch and I find it a hugely welcome
development. Thank you Edward for taking the time to implement it.
> If I have missed any Boost libraries which have a close C++ standard
> equivalent just tell me and I will add it with some added tests for that
> particular library.
I didn't see system_error?
> 5) I wanted to push it to 'develop' and let others use it and add the
> per library PR's to test it. If it was found to be flawed or could be
> better in any way I could then change it on 'develop', and if people
> were satisfied with it as a workable solution it could eventually be
> merged to 'master'. If not it could be easily removed if necessary since
> it exists in its own header files apart from the rest of Boost.config.
> Even its documentation is a separate Boost.config .qbk file.
Here's a crazy idea: If Boost.Build is in >= C++ 11 build mode, turn
all these macros on by default. That should ease testing enormously.
Build needs to gain an official C++ 11 build mode first though.
Something where libraries in their Jamfile can say "I can only
compile with C++11 or better, so if not >= C++ 11 then ignore this
library during build".
> If there are better interoperable systems I would love to hear about
> them. But for me personally any system where I have to jump through
> hoops simply to be able to write code which works whether I am using a
> Boost library or its C++ standard library equivalent, will not be worth it.
I think this support is a great first step to making Boost less
obsolete in a C++ 11 world. It doesn't solve all the other problems
Boost has, but it's still a huge improvement.
> Questions, concerns etc are welcome.
My only real worry is the ABI problems. You need to permute the
symbols being linked to avoid config mismatches colliding in an
unhelpful way.
Perhaps for each config macro have during build the library output an
extern dll visible empty function with a mangled name representing
the config. On use, import and use that function. This should
generate link errors if one is trying to use a config against a
binary not built the same way.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk