On 15 May 2015 at 8:59, John Maddock wrote:
This isn't the claim.
Well that's certainly how it read to me, in fact it seemed to me that you were originally advocating "lets throw everything away and start again".
That's where I was two years ago, even a year ago. I now have a viable migration path from 03 to modular 14 for existing Boost libraries. For those library maintainers which invest the effort to make their code base support both, I see no reason their library won't continue into the long term. If they remain wedded to 03 and refuse to support any 11 or any modularity, well I believe the users will vote with their feet on that over time.
The claim is that so long as the libraries in Boost which depend on STL11 equivalents cannot use the STL11 equivalent, they are suffering from at least these problems:
1. An inability to easily interoperate with code which uses the STL11 primitives e.g. std::future. Yes that can be an issue, but it's easily addressed via Boost.Config #ifdef's.
Some time back I changed Math to use std::tuple internally when available, now we're starting the process of exposing that to end users so they can use *any* suitable tuple type (including the 2 different versions in Boost, plus tr1 and std versions). The code doesn't care which, that's what generic code is for ;)
For sure adding C++ support to older libraries may sometimes seem slow - but it's demand driven - unless there's a really good case for changing things lib authors are understandably cautious (and don't even get me started on noexcept specifiers!!)
Basically if it's working perfectly well now, there has to be a good reason for major architectural changes, and those have to be handled on a case by case basis.
That's just about the worst way to add C++ 11 support. You get problems with ABI conflicts, violation of ODR, and additional bloat. As an absolute minimum, you need to combine such macros switching std::tuple usage into custom namespace. This prevents collision, violation of ODR, though does little for bloat. APIBind does exactly the above - custom namespace generation via macro programming, using inline namespaces to make this underlying solution hidden to code using your library.
2. A compile time and binary bloat deficiency, sometimes very substantial. Really? Why would the Boost versions be so much larger than the std versions? Can you give an example?
It's mostly a case of duplication of functionality, but as a single example I can see that a move capturing c++ 14 lambda is going to be ton more efficient than a std::function built using std::bind. C++ 11 is also much better at eliding unnecessary code.
4. A potential deficiency in reliability and quality, as the STL11 Boost equivalents are probably not as well tested, audited, and maintained as the STL11 editions simply due to resources invested. I disagree strongly, often the Boost versions are mature, portable, heavily tested and in widespread use. IMO we haven't even begun to shake out all the bugs in the some of the std versions yet.
Mature yes. The rest utterly no. The STL maintainers on this list may chime in here, I'll leave it to them.
Do you realise that GCC completed it's C++11 support only in the most recent 5.1 release? Or that <regex> was a non-functioning stub until 4.9?
I probably have a better idea than you. I am at C++ Now right now after all, and these issues have come up in *detail* ... :)
And I haven't even even mentioned Boost-specific extensions - if you need full Perl compatibility then it's pcre or Boost.Regex, std::regex doesn't get there for example.
Sure. If you really need the Boost edition, you're going to need it no matter what. I'm talking about the 80-90% of use cases not using any of the extended functionality, or able to not use the extended functionality. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/