Subject: Re: [boost] [Config] Support for switching between std:: andboost:: equivalents.
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-06-07 13:04:14
On 07/06/2015 15:36, Peter Dimov wrote:
> Edward Diener wrote:
>> Most of the talk about the problems of my macro system presupposes
>> that programmers using Boost will mistakenly try to use a C++11
>> version of a library during a C++03 mode build and vice versa, and
>> therefore the system must be flawed.
>
> This was some of the talk but I'm not sure about "most". A substantial
> part of the talk was about programmers wanting to use boost::regex
> even when the compiler happens to be in C++11 mode. In other words,
> talk that challenges your assumption that
>
>> If the end-user of my library is compiling in C++11 mode is it more
>> likely that his use of regex will be std::regex or boost::regex ? IMO
>> it is the former.
>
> There are several good reasons to prefer boost::regex. First, the one
> I pointed out, you want to maintain a single code base that compiles
> under C++03 and C++11. Second, you want to use boost::regex's
> extensions that std::regex doesn't have. Third, you want predictable
> performance that is independent of the standard library in use.
>
Right. But if lib X prefers/needs to use the Boost version always, they
don't have to use this mechanism.
> On the other side of the coin, we have the desire to avoid use of
> Boost when use of standard facilities would suffice, which is real and
> legitimate. However, in my experience at least, this desire is only
> strong when you can avoid use of Boost _altogether_, which is not the
> case under discussion.
Right, we're nowhere near having a package manager that's smart enough
to avoid dependence on boost::whatever if the user tells it they have a
C++11 compiler.
I guess my concerns are somewhat different from those already expressed:
* I'm not sure that this adds much over the existing macros
BOOST_NO_CXX11_HDR_REGEX etc.
* If this evolved into a more "complete" solution, then (a) It doesn't
belong in Config (too many dependencies), and (b) I would worry that we
repeat the mistake of Boost.TR1 - which is to say creating that
particular unmaintainable monster it in the first place -just ask the
author ;)
* Folks are correct to be concerned about ABI issues: we not that long
ago changed 'nix installs to install "one true binary" for each library
as there was *very* strong user preference for that. Splitting into '03
and '11 binaries is IMO a significant retrograde step. If you do that
expect endless newbie support requests wondering why things don't work.
On the other hand:
* I can see a legitimate use for this as a library internal (rather like
what Math does with std::tuple and boost::tuple).
* The need to have different linking requirements in Boost.Build is a
solved issue - just use check_target_builds to set the dependency.
So... I guess what I would like to see expressed, is what are the
concrete use cases for this? What do *you* want to use it for?
And finally, you are aware that there are 3 tuples available? boost::,
fusion:: and std::, and they they all are slightly different? Oh and
std::tr1::tuple too ;)
What I suspect we will see more of, is libraries becoming implementation
agnostic - "give me something that looks like a
tuple/thread/future/function and I'll go off and do the right thing".
The latest Math code does that with tuple types, and it was a pain in
the neck to get working (or possibly I was just being dense at the
time), certainly the hoops you have to jump through to support that go
way beyond the scope of this addition.
Regards, John.