June 2014 - Boost - lists.preview.boost.org

Boost 1.56 timeframe
by Jonathan Jones 03 Jun '14

03 Jun '14

Hi folks, Is there a timeframe for the release of Boost 1.56? The current 1.56 page simply states that it's at an early stage in its release cycle (but it has said this for months). http://www.boost.org/users/history/version_1_56_0.html I'm asking in the context of Visual Studio 2013. Boost 1.55 is known to have issues with VS2013, which I'm hoping the 1.56 release would address. Sincerely, Jonathan Jones

7 10

Pervasive dependency upon mpl::bool_
by Peter Dimov 03 Jun '14

03 Jun '14

We have lots of headers that depend on mpl::bool_ in order to define traits classes as deriving from mpl::true_ or mpl::false_. I don't think that this dependency is necessary even for MPL interoperability. The normal way of template<class T> struct trait { BOOST_STATIC_CONSTANT( bool, value = false ); }; should work just as well. I think. As one example, there's detail/blank.hpp, which starts with #include "boost/mpl/bool.hpp" #include "boost/type_traits/is_empty.hpp" #include "boost/type_traits/is_pod.hpp" #include "boost/type_traits/is_stateless.hpp" It doesn't really need these includes. namespace boost { struct blank { }; // type traits specializations // template <> struct is_pod< blank > : mpl::true_ { }; This can be written as template<class T> struct is_pod; template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; which requires no includes. The problem is, though, that all type traits do derive from mpl::true_ or mpl::false_, and I'm not sure if rewriting blank.hpp in the above manner is actually correct. Should type trait specializations always derive from mpl::true_ or mpl::false_? Will I break something if I specialize a type trait to not derive from mpl::bool_? Or is a nested ::value enough? Who knows. :-) But really, if a header, whose entire purpose is to define an empty struct, can't get by without including type traits and mpl, we've lost the dependency game before it's even started.

7 22

[atomic] Help understanding consume order
by Andrey Semashev 03 Jun '14

03 Jun '14

Hi, I'm reviewing (again) Boost.Atomic code and struggling to understand the consume order and in particular what should it mean on architectures other than DEC Alpha. I read the explanation here: http://en.cppreference.com/w/cpp/atomic/memory_order but the point eludes me. Take ARM for example and the explanation in the "Release-Consume ordering" section. The producer thread allocates the string and stores the pointer with a release operation, so that the pointer, the string contents and the 'data' integer are visible to other threads. Now the consumer thread reads the pointer with a consume operation. According to the explanation in the article, on ARM the consume operation need not issue any specific fences to be able to use the pointer and the string body. In that case, the consume operation becomes equivalent to relaxed (plus prohibiting compiler optimizations). But is there a guarantee that the string body will be visible to the consumer? Shouldn't the consume operation be promoted to acquire instead? I guess, that's the ultimate question: how should consume ordering be handled on conventional architectures?

3 6

[iterator][range] Old breaking change in develop.
by Daniel James 02 Jun '14

02 Jun '14

Hi, There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it): https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bd… Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted. Daniel

3 3

github issue
by Christian Henning 02 Jun '14

02 Jun '14

Hi all, I'm cloning boost but something went wrong when trying to get the python submodule. I'm not sure if the problem is related to boost, github, my git setup, or maybe my internet connectivity. Here is a snippet from the console output: ... Cloning into 'libs/proto'... remote: Reusing existing pack: 4233, done. remote: Total 4233 (delta 0), reused 0 (delta 0) Receiving objects: 100% (4233/4233), 1.89 MiB | 893.00 KiB/s, done. Resolving deltas: 100% (2062/2062), done. Checking connectivity... done. Cloning into 'libs/ptr_container'... remote: Reusing existing pack: 2887, done. remote: Total 2887 (delta 0), reused 0 (delta 0)Receiving objects: 98% (2830/28 87), 2.36 MiB | 924.00 KiB/s Receiving objects: 100% (2887/2887), 2.78 MiB | 924.00 KiB/s, done. Resolving deltas: 100% (1839/1839), done. Checking connectivity... done. Cloning into 'libs/python'... ssh: github.com: no address associated with name fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Clone of 'git@github.com:boostorg/python.git' into submodule path 'libs/python' failed I'm using git version 1.9.0.msysgit.0 on Windows 7. Anyone know what's going? Thanks, Christian

2 2

Re: [boost] [modularization] proposal and poll
by Niall Douglas 01 Jun '14

01 Jun '14

I'll top post my reply as Robert's valuable post didn't make it onto the list again. Please do read his reply below, it's worth reading as Robert is one of the lead thinkers on the steering committee about this. Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries. I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are. If their maintainers - or a sponsor - are willing to do: 1. Make their library entirely C++ 11/14 STL based, porting only the absolute minimum of old Boost. 2. C++ Modules ready i.e. restructured and reorganised to properly fit C++ Modules. 3. Contribute any general utility code to the core utilities library, not duplicating any functionality there, and in a form suitable for entering the C++ 17 STL. 4. Meet the raised unit test and CI soak test and sanitiser/valgrind requirements. Then they have a good chance of their library appearing highly ranked in the list of C++ 14 Boost libraries, where that ranking is generated by a set of clang AST analysers. Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again. Right now with the present situation there are few incentives to sacrifice family time. That needs to change for Boost to survive, else the continuing slow decline will continue. Niall On 29 May 2014 at 17:52, Robert Ramey wrote: > > > On Thursday, May 29, 2014 2:17:11 PM UTC-7, Niall Douglas wrote: > > > > On 29 May 2014 at 22:22, Julian Gonggrijp wrote: > > > > If a fork of Boost becomes necessary later this year, > > > LOL - this is not going to be necessary. > > > > The hard part isn't what to do. > > > LOL - not for you! > > > > The hard part is gaining community > > buy in when "their" code gets broken by the necessary changes. I have > > concluded it isn't possible, > > > LOL - you've underestimated the amount of work to convert > everything to C++11 by a factor of .... 1000 ? Basically it's > a whole rewrite of 100 modules. And the gain is ....? > > hence me proposing a fork where such > > "radical" changes won't upset anyone. > > > Your free to do this. And you should if you really believe that > it would benefit anyone or anything. > > > I think it may be easier for the steering committee to justify any > > > decision on this proposal, > > > The steering committee doesn't have anything to decide here. The > "Proposal" is: > > 1. Reduction of dependencies between Boost libraries. > > It's not clear what action is being proposed - but I'm pretty sure > the steering committee won't be doing it. > > 2. Simple but effective automation of dependency handling. > > I'm pretty sure the steering committee won't be doing this either. > If anyone believes that they can implement "simple and > effective" automation of dependency handling - just go ahead > and do it and let us see it. > > > > Decisive and immediate action on this is vital if Boost is to > > survive. I vote yes to both, ASAP. > > > > LOL - There is wide agreement that boost has growing pains and > will have to evolve. But I haven't seen any proposals for > "Decisive and Immediate" which would do anything but make > things worse. > > And since you've got me started - Here is what boost needs go to the next > step. > > a) Make the review process more effective and efficient - we're taking real > practical action to address this now. The jury is still out regarding the > effectiveness of our efforts - but we ARE actually doing something. > > b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11 > and C++14. Our infrastructure doesn't explicitly address this. The > following > needs to change > 1) for each library we need to explicitly state somewhere what > version(s) of C++ the > library is meant to support. > 2) support running of tests and builds for only those platforms. > > I've suggested that we enhance B2 to address this. So far > no one has responded to this suggestion > > Note that this would have he effect of encouraging libraries to evolve > to later versions of C++ with minimal disruption to both library > authors and users. > > c) Decouple Deployment of Boost Libraries from the Certification > of boost libraries. Beman has noted that what he would like to > see is something like CYGWIN whereby one specifies what one > want's and somehow automagically you get that plush what you > need. I realize that this is more or less what is being suggested here. > But no one has presented credible proposal for making it it happen. > > This would also address the issue of "old" libraries. As they > fall into disuse are become superseded by newer ones, the can > still be in boost even though their frequency of deployment drops off. > > The above constitutes a real path forward. This is what Boost > needs for the next 15 years. > > Robert Ramey > -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 4

throw or boost::throw_exception?
by Andrzej Krzemienski 01 Jun '14

01 Jun '14

Hi, I am not sure where, but I am convinced that I have read that it is recommended for Boost libraries that they not use naked throw expressions but instead call boost::throw_exception. Is that true? If so, it enforces a dependency of more than half Boost libraries on Boost.Exception. Am I right? If so, is this the right recommendation in the context of the discussion about reducing dependencies between the libraries? Regards, &rzej

8 22