September 2013 - Boost - lists.boost.org

[predef] [git] Do the tests need an explicit <dependency>
by Steven Watanabe 22 Sep '13

22 Sep '13

AMDG The property <dependency>$(BOOST_PREDEF_INCLUDE_ROOT)/boost/predef.hpp interferes with testing under the git layout, because this header is generated as part of the build. Is there a reason for it? The dependency should be found by the #include scanner. In Christ, Steven Watanabe

2 1

[config] Visual C++ 2013 RC support - variadic template failures
by Beman Dawes 22 Sep '13

22 Sep '13

I updated boost/config Visual C++ support yesterday to add Visual C++ 2013 RC support. But Mat Berchtold reported that signals2 tests then started to fail. I confirmed that 2013 RC tests were failing for signals2 and several of its dependencies, and narrowed it down to variadic templates so reverted to defining BOOST_NO_CXX11_VARIADIC_TEMPLATES for 2013 RC. --Beman

3 6

[Operators] empty_base should be untemplated?
by Andrew Ho 21 Sep '13

21 Sep '13

I've noticed about the empty_base class is that it's templated with type T, and I don't think it should be. Fyi, the empty_base class is there to turn multiple inheritance into a single inheritance chain (due to compiler deficiencies/object size bloat on at least Visual Studio). I don't see why this empty_base should be templated, and it would be better suited if it wasn't since all I can think it does is make the compiler work harder. Does anyone know why it was templated to begin with? Additionally, are we safe to change empty_base to be not use templates?

4 4

Boost reviews
by Edward Diener 21 Sep '13

21 Sep '13

I have not seen any new reviews of libraries for Boost in a long time. Is this because: * There are very few libraries on the review queue. * There are no people willing to act as review managers for library reviews. * Boost already has so many libraries that an effort has been made to slow down reviews to a great extent. * There is little interest for new Boost libraries in the community of developers who follow Boost. * The transition to git and ryppl is taking precedence before any new libraries will be reviewed. * There are not enough reviewers when a library does have a review in order to decide whether or not a library should be accepted into Boost. Or perhaps some combination of these possibilities. As someone who still would like to see my variadic data library be reviewed for possible acceptance into Boost I am most curious to know the reasons why no new libraries appear to be getting reviewed anymore.

5 7

[multi_index][intel-linux-14.0.0][repost] Help needed debugging initializer list support
by Joaquin M Lopez Munoz 21 Sep '13

21 Sep '13

Hi, Any kind soul can help with this? Reposting: The trunk version of Boost.MultiIndex introduces support for initializer list, which seems to work fine with regression tests except for intel-linux-14.0.0: http://tinyurl.com/pclssoe http://tinyurl.com/nzwzpu6 which spits error messages like this (replaced large chunks of text with *** for clarity): ../libs/multi_index/test/test_modifiers.cpp(230): error: no instance of overloaded function "boost::multi_index::detail::hashed_index<***>::insert [***]" matches the argument list argument types are: ({...}) object type is: employee_set_by_name i1.insert({{4,"Vanessa",20,9236},{5,"Penelope",55,2358}}); At first I thought this is failing because for it to work the compiler should not only support initializer lists but also C++11 unified initialization syntax, but I think this is not the problem because a) intel-linux-14.0.0 does indeed seem to support unified initialization syntax, since BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX is not listed in http://tinyurl.com/ndutn2w . b) the following test code also fails: s.assign({0,1,2,3,4,5}); with s a multi_index_container of ints, and this does not depend on unified initialization syntaxes. The error message here, FWIW, is different than before: ../libs/multi_index/test/test_copy_assignment.cpp(56): internal error: assertion failed: node_has_side_effects: bad node kind (shared/cfe/edgcpfe/il.c, line 20611) The tested code seems simple enough, for instance lines 271 and following of multi_index_container.hpp look like: #if !defined(BOOST_NO_CXX11_HDR_INITIALIZER_LIST) multi_index_container( std::initializer_list<Value> list, const ctor_args_list& args_list=ctor_args_list(), const allocator_type& al=allocator_type()) [...] and the ofending assign member function in sequenced_index.hpp is as innocent as: #if !defined(BOOST_NO_CXX11_HDR_INITIALIZER_LIST) void assign(std::initializer_list<value_type> list) { assign(list.begin(),list.end()); } #endif Besides, other libs with initializer list support such as Boost.SmartPtr and Boost.Unordered cope fine with this compiler. Clues? Any help much appreciated. Joaquín M López Muñoz Telefónica Digital

1 0

Policy about non-compliant standard headers
by Andrey Semashev 21 Sep '13

21 Sep '13

Hi, I was reported an issue with Boost.Log which fails to compile with Sun Pro compiler because it has non-compliant standard C headers. I was wondering if there is a policy or recommendation for dealing with this kind of problems. I know there is Boost.Compatibility [1] created exactly for this problem. There are many places I include C headers in my code, so relying on Boost.Compatibility would be an ideal solution for me so I don't have to cripple my code. However, I see that many libraries deal with missing std::C symbols themselves. Why do that and not leave it to Boost.Compatibility? By that I mean require users to add it in include path of the compiler. There is one more point to consider. The issue with the broken standard headers is a sign of an ancient compiler. And if the compiler vendor by 2011 (when Sun Studio 12.3 was released) doesn't manage to ship conforming 1998 headers, I'd still consider it an ancient compiler. Boost recently removed (removing?) support for ancient compilers. So, should I bother supporting this compiler at all? [1] http://www.boost.org/doc/libs/1_54_0/libs/compatibility/

3 7

Boost::Units - mapping from units object to something else
by david.hagood＠gmail.com 21 Sep '13

21 Sep '13

I'm looking at the Boost::Units classes to help eliminate a family of programming errors, but there is one thing that I'm having difficulty with: I have a collection of objects of my own type that pertains to units - these are of a fixed type, with instances per type of unit. I'd like to somehow be able to map from the units constants that Boost uses (e.g. boost:units:si:watts) into my objects (return the correct instance for "watts"). Obviously, there's going to be some hand coding to make that happen - it is unlikely to be possible to generate that mapping automatically. Ideally, what I'd like to do would be to have something like template <typename Unit> struct MyMapper { static const MyUnitInfo info; }; template <> const MyUnitInfo<boost::units::si::watts>::info(/*ctor parms for my type */); and do things like: MyMapper<boost::units::si::watts>::info to get the appropriate structure. However, since all the various Boost units are in a type hierarchy to express dimensionality, I'm at a loss how to compose a template to allow something like that to happen - it certainly isn't as straightforward as the above, since Boost units instances of varying types, not typenames. Likewise, just defining some form of map: std::map<???,MyUnitInfo> mymap = boost::assign::map_list_of (boost::units::si::watts,MyUnitInfo(/* my parms*/)) (boost::units::si::ohms,MyUnitInfo(...)); won't work as the types for the Boost constants are all different as far as I can see. Is there some base type all the Boost::Units constants extend, such that I could test for that?

3 3

Boost.Mock ?
by Mathieu Champlon 21 Sep '13

21 Sep '13

Hello, Would a library for mock objects be of interest ? The documentation can be found here : http://mat007.users.sourceforge.net/boost_mock/ An archive is also available for download there : http://sourceforge.net/projects/mat007.u/files/boost-mock.zip It's been converted from turtle (http://turtle.sourceforge.net/) which was mentioned on the mailing-list a couple of times in the past. There is a catch in that it needs Boost.Test from the release branch and doesn't compile with the trunk. The changes are minimal though and I can provide a patch if anyone is interested. Would the library be worth a review ? In the meanwhile I would be highly interested in any feedback ! Thank you, MAT.

4 4

Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a
by Renato Forti 20 Sep '13

20 Sep '13

Hi All, I have a new version of Boost.Application! In this release all requested features that boost users suggested (in boost user group) are addressed, based on release 1 and release 2, including: 1) Provide more "Boost Way" interface 2) Use Boost.Parameter to give flexibility for future extensions. 3) Access and change environment variables. 4) Simple class (shared_library) to allow use of dynamic libs as plug-in (extending application). 5) Wide string support (Windows). 6) Use Boost.System on Error Handling 7) Setup module for windows service installation. To install, download file: https://downloads.sourceforge.net/project/boostapp/Boost.Application_beta_3a .zip?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fboostapp%2F&ts=1379614495& use_mirror=master or https://sourceforge.net/projects/boostapp/files/ and copy application to your boost installation folder! You don't need build it, the lib is header only, but have some dependences. The documentation is still pretty bad, but it is the right place for you to start with lib! Please, send your questions, to: re.tf(a)acm.org Thanks -- Renato

5 7

[asio] Compilation failures on mingw
by Andrey Semashev 20 Sep '13

20 Sep '13

Hi, I'm seeing test failures on MinGW [1], which are probably caused by commit 85764 [2]. Could this be fixed? [1] <http://www.boost.org/development/tests/trunk/developer/MinGW-32%20jc-bell-c…> [2] <https://svn.boost.org/trac/boost/changeset/85764>

1 0