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.