- Boost-users - lists.preview.boost.org

[Boost.Test] What's the best way to make custom assertions?
by legalize+jeeves＠mail.xmission.com 31 Oct '12

31 Oct '12

[Please do not mail me a copy of your followup] I want to make custom assertion methods that report the failure location as the place where the custom assertion is invoked, not the location where the BOOST_REQUIRE_xxx macros are used in the implementation of the custom assertion. In my own code, when I wanted to do report the point of invocation instead of the point of implementation, I implemented my code along the lines of void report(char const* file, int line) { // ... // output a message using line and file // ... } #define REPORT() report(__FILE__, __LINE__) void code() { REPORT(); // report something interesting here } When I look at how the assertion macros are implemented in Boost.Test, it seems that __FILE__ and __LINE__ are substituted down pretty far in the macro invocation chain. This means that if I want to write my own custom assertion that reports messages at the point of invocation and not at the point of implementation, I have to call these very low-level macro facilities and duplicate a bunch of stuff that's in Boost.Test. One thing I don't want to do is make a gigantic multi-line macro for my custom assertion. I really don't like using macros for things that could be done with functions and a custom assertion, IMO, falls into that category. Is there a clean way of implementing a custom assertion in the manner I've described without replicating a bunch of the intermediate layers of Boost.Test's macros? Gennady, if you're reading this and there isn't a clean way of doing what I'd like, are you willing to accept a refactoring changeset that promotes __FILE__ and __LINE__ arguments higher in the macro call chain? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

3 7

[mpi] many undefined references to serialize<boost::mpi::detail::mpi_datatype_oarchive>
by Brian Budge 30 Oct '12

30 Oct '12

Hi all - I've got a class hierarchy that can already be serialized into text or binary archives. I'm explicitly instantiating the template functions for serialize and/or load/save. I'm trying to add the capability to have boost mpi perform the serialization through send/recv/broadcast. I've added explicit instantiations for the boost::mpi::packed_iarchive and packed_oarchive. My code compiles, but at the end I get a bunch of undefined references for serialize<boost::mpi::detail::mpi_datatype_oarchive>. I can add the explicit instantiations for this oarchive, and this seems to fix my linking issue, but this seems broken, i.e. I should not have to deal with anything in a boost::detail namespace? Is there another suggestion for how to get this to work? Thanks, Brian

5 11

[MPI] missing symbols using serialization's static library design
by Barrett, Brian W 30 Oct '12

30 Oct '12

Hello all - On Mac OS X Lion, we're seeing errors when linking our application using Boost.MPI. The application is rather large and uses Boost.Serialization for both checkpoint/restart and MPI communication. The checkpoint/restart bits made serialization a bit of a disaster in terms of compile times (due to headers including basically every other header in the project). To solve that problem, we followed the Boost.Serialization advice on static libraries, and all is good. Except that on Lion (and possibly elsewhere, but definitely on Lion) using the gcc front-end (i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)), we're seeing link failures due to serialization calls for MPI archivers not being found when compiling with -O2 or higher on Boost 1.50.0 and 1.51.0: CXXLD sst.x Undefined symbols for architecture x86_64: "void SST::Introspector::serialize<boost::mpi::packed_iarchive>(boost::mpi::packe d_iarchive&, unsigned int)", referenced from: boost::archive::detail::iserializer<boost::mpi::packed_iarchive, SST::Introspector>::load_object_data(boost::archive::detail::basic_iarchive &, void*, unsigned int) const in introspectedComponent.o boost::archive::detail::iserializer<boost::mpi::packed_iarchive, SST::Introspector>::load_object_data(boost::archive::detail::basic_iarchive &, void*, unsigned int) consti n simulation.o While I could simply explicitly insatiate the missing archivers, that seems like a bad idea for something in the detail namespace and it appears that the list of archivers I'd need to instantiate has changed over time. Is there a better solution to the problem? There's a test case the exhibits the problem available here on our Google code project bug tracker. It's essentially the Boost.Serialization demo_pimpl example, but using MPI instead of a text archiver. The code is at: http://sst-simulator.googlecode.com/issues/attachment?aid=280000000&name=mp i_serialization_test.tar.gz&token=1MTkBuFrhrfUUAZRZYH3kZrElIg%3A13500682075 60 Thanks, Brian -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories

3 5

[boost build] Where/How is python found?
by Gottlob Frege 30 Oct '12

30 Oct '12

I'm trying to determine how boost build finds the python install. I see in boost\tools\build\v2\tools\python-config.jam that it looks in the Windows Registry (for NT at least). But this only checks for Python 2.4, 2.3, 2.2. It also seems to look for python.exe in the PATH. But I can't seem to find the code that does that. Any ideas? In particular, I would like to change it to actually check for an include directory once it finds python.exe. On my system, it finds a 'rogue' python.exe that is not part of the full python install (thus no include folder). Tony

2 2

[Boost.Test] Always leaving test code active in Release mode
by Ruediger Berlich 30 Oct '12

30 Oct '12

Hi there, we use Boost.Test to do Unit tests for the Geneva library, covering parametric optimization. Code for tests is included directly in most classes, so tests can be written "on-site", whenever a new feature is added. However, in Release mode, usually test-functions are *not* included (masked by an "#ifdef GEMTESTING" block), but can be switched on by the user prior to compilation. When this happens, it means that classes being tested have a different interface than classes without the GEMTESTING-define set. Users are meant to derive their own classes from the Geneva's core classes and overload certain functions. They are also provided with a test infrastructure, that allows them to test their own code without too much trouble for compliance with the libraries rules (as just one example, it is being tested whether their code can be serialiazed using Boost.Serialization and whether de-serialized classes are identical to the one being serialized). However, when users compile our (Open Source) library with the GEMTESTING-define set and then compile their own code without this flag, they will include headers with a different interface than the one being used to compile the library. This has led to some very hard to detect failures. We are looking for ways to circumvent this source of errors and so far see three options: a) We can give compiled libraries a different name when the test-code is included (e.g. libgeneva-testing.so or the likes) b) There could be sanity checks in the code, e.g. with a static function returning different values depending on whether test code is activated or not c) We can always compile the test code, even in Release mode, by removing the "#ifdef GEMTESTING", this leaving no ambiguities regarding the API Option a) will effectively double compilation times, as we will always have to compile both library variants. It would also force us to make many changes in the CMake-based build system. Option b) leaves a source for frustration for our users, as they will only discover the problem when compiling and/or running their code. Option c) is the easiest to implement, but leaves open some questions (see below) *** My question now is, what the trade-offs of option c) are (i.e., leaving all test code in and always linking with the Boost.Test libraries). Do we loose anything ? Will this affect our ability to debug the code ? Are there runtime-penalties ? Note that none of the test-functions is called during normal execution. *** Of course any views on a good strategy for the above scenario are also appreciated. In any case thanks and best regards, Ruediger

1 0

Typedef rejected when disambiguating a call to boost::assign
by mark pashley 30 Oct '12

30 Oct '12

I am trying to initialise a std::map of std::set using boost::assign, as follows: typedef std::set< uint32_t > the_set_t; typedef std::map< uint32_t, the_set_t > the_map_t; the_map_t data = boost::assign::map_list_of< uint32_t, the_set_t > > // bad line ( 1, boost::assign::list_of(10)(20)(30) ) Unfortunately this is rejected by GCC 4.4.6, and results in a large amount of errors, (attached below). The problem is caused by the use of the typedef the_set_t. If the typedef is replaced with std::set<uint32_t> the code compiles and works correctly. the_map_t data = boost::assign::map_list_of< uint32_t, std::set< uint32_t > > The error produced is as follows: map-assign.cpp:19: error: conversion from ‘bool’ to non-scalar type ‘the_map_t’ requested In file included from /opt/boost_1_51_0/boost/assign/list_of.hpp:397, from map-assign.cpp:7: /opt/boost_1_51_0/boost/preprocessor/iteration/detail/local.hpp: In member function ‘boost::assign_detail::generic_list<T>& boost::assign_detail::generic_list<T>::operator() (const U&, const U0&) [with U = int, U0 = boost::assign_detail::generic_list<int>, T = int]’: map-assign.cpp:17: instantiated from here /opt/boost_1_51_0/boost/preprocessor/iteration/detail/local.hpp:37: error: functional cast expression list treated as compound expression In file included from /opt/boost_1_51_0/boost/iterator/iterator_categories.hpp:15, from /opt/boost_1_51_0/boost/iterator/detail/facade_iterator_category.hpp:7, from /opt/boost_1_51_0/boost/iterator/iterator_facade.hpp:14, from /opt/boost_1_51_0/boost/range/iterator_range_core.hpp:23, from /opt/boost_1_51_0/boost/range/iterator_range.hpp:13, from /opt/boost_1_51_0/boost/assign/list_of.hpp:20, from map-assign.cpp:7: /opt/boost_1_51_0/boost/mpl/eval_if.hpp: At global scope: /opt/boost_1_51_0/boost/mpl/eval_if.hpp: In instantiation of ‘boost::mpl::eval_if_c<false, boost::range_const_iterator< boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)>, boost::range_mutable_iterator< boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)> >’: /opt/boost_1_51_0/boost/range/iterator.hpp:63: instantiated from ‘boost::range_iterator< boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)>’ /opt/boost_1_51_0/boost/range/iterator_range_core.hpp:72: instantiated from ‘bool boost::iterator_range_detail::less_than(const Left&, const Right&) [with Left = boost::assign_detail::converter< boost::assign_detail::generic_list<int>, std::_Deque_iterator<int, int&, int*> >, Right = boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)]’ /opt/boost_1_51_0/boost/assign/list_of.hpp:274: instantiated from ‘bool boost::assign_detail::operator<(const boost::assign_detail::converter<T, I>&, const Range&) [with T = boost::assign_detail::generic_list<int>, I = std::_Deque_iterator<int, int&, int*>, Range = boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)]’ /opt/boost_1_51_0/boost/assign/list_of.hpp:292: instantiated from ‘bool boost::assign_detail::operator>(const Range&, const boost::assign_detail::converter<T, I>&) [with T = boost::assign_detail::generic_list<int>, I = std::_Deque_iterator<int, int&, int*>, Range = boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)]’ map-assign.cpp:19: instantiated from here /opt/boost_1_51_0/boost/mpl/eval_if.hpp:60: error: no type named ‘type’ in ‘struct boost::range_mutable_iterator< boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)>’ In file included from /opt/boost_1_51_0/boost/range/iterator_range.hpp:13, from /opt/boost_1_51_0/boost/assign/list_of.hpp:20, from map-assign.cpp:7: /opt/boost_1_51_0/boost/range/iterator_range_core.hpp: In function ‘bool boost::iterator_range_detail::less_than(const Left&, const Right&) [with Left = boost::assign_detail::converter<boost::assign_detail::generic_list<int>, std::_Deque_iterator<int, int&, int*> >, Right = boost::assign_detail::generic_list<std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)]’: /opt/boost_1_51_0/boost/assign/list_of.hpp:274: instantiated from ‘bool boost::assign_detail::operator<(const boost::assign_detail::converter<T, I>&, const Range&) [with T = boost::assign_detail::generic_list<int>, I = std::_Deque_iterator<int, int&, int*>, Range = boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)]’ /opt/boost_1_51_0/boost/assign/list_of.hpp:292: instantiated from ‘bool boost::assign_detail::operator>(const Range&, const boost::assign_detail::converter<T, I>&) [with T = boost::assign_detail::generic_list<int>, I = std::_Deque_iterator<int, int&, int*>, Range = boost::assign_detail::generic_list<std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&)]’ map-assign.cpp:19: instantiated from here /opt/boost_1_51_0/boost/range/iterator_range_core.hpp:72: error: no matching function for call to ‘begin(boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (&) (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&))’ /opt/boost_1_51_0/boost/range/iterator_range_core.hpp:72: error: no matching function for call to ‘end(boost::assign_detail::generic_list< std::pair<unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > > > (&) (const unsigned int&, const std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&))’ In file included from map-assign.cpp:7: /opt/boost_1_51_0/boost/assign/list_of.hpp: In member function ‘Container boost::assign_detail::converter<DerivedTAssign, Iterator>::convert( const Container*, boost::assign_detail::default_type_tag) const [with Container = int, DerivedTAssign = boost::assign_detail::generic_list<int>, Iterator = std::_Deque_iterator<int, int&, int*>]’: /opt/boost_1_51_0/boost/assign/list_of.hpp:142: instantiated from ‘Container boost::assign_detail::converter<DerivedTAssign, Iterator>::convert_to_container() const [with Container = int, DerivedTAssign = boost::assign_detail::generic_list<int>, Iterator = std::_Deque_iterator<int, int&, int*>]’ /opt/boost_1_51_0/boost/assign/list_of.hpp:436: instantiated from ‘boost::assign_detail::generic_list<T>::operator Container() const [with Container = int, T = int]’ /opt/boost_1_51_0/boost/preprocessor/iteration/detail/local.hpp:37: instantiated from ‘boost::assign_detail::generic_list<T>& boost::assign_detail::generic_list<T>::operator()(const U&, const U0&) [with U = int, U1 = boost::assign_detail::generic_list<int>, T = int]’ map-assign.cpp:17: instantiated from here /opt/boost_1_51_0/boost/assign/list_of.hpp:163: error: functional cast expression list treated as compound expression /opt/boost_1_51_0/boost/assign/list_of.hpp:163: error: invalid cast from type ‘std::_Deque_iterator<int, int&, int*>’ to type ‘int’ What is wrong with using a typedef or is this a known limitation of `boost::assign`? -- View this message in context: http://boost.2283326.n4.nabble.com/Typedef-rejected-when-disambiguating-a-c… Sent from the Boost - Users mailing list archive at Nabble.com.

2 5

shared_ptr on aix
by Vojtech Fried 30 Oct '12

30 Oct '12

Hi, What is the status of boost/smart_ptr/detail/sp_counted_base_aix.hpp? It is not #included by default in sp_counted_base_aix.hpp. Is it safe to use or is it just an exprerimental version? We have a multiplatform application and I am trying to make some improvements for it on AIX platform. One candidate right now is to utilize sp_counted_base_aix.hpp (boost/smart_ptr/detail/sp_counted_base_aix.hpp). It implements atomic counter without (pthread) mutexes. Using it improves performance of our app up to 10%. But sp_counted_base_aix.hpp is not used by default. I had to add an #ifed to sp_counted_base.hpp to make it work. I tested the implementation with a small sample program that copied and removed shared_ptrs in multiple threads and it works. But I am still concerned. How widely is this AIX specific implementation used? How risky is it for us to use it? Best regards Vojtech

1 0

Boost.Test ordering
by John M. Dlugosz 30 Oct '12

30 Oct '12

If I make unit tests in different source files, I need to declare a BOOST_AUTO_TEST_SUITE in each one, right? At link time, these appear in some undetermined order. How can I cause them to be run in the desired order instead? —John

1 0

boost::container::vector fails to compile with C++03 compiler
by mark pashley 30 Oct '12

30 Oct '12

The following example compiles fine when using GCC 4.4.6 with the --std=c++0x flag but fails to compile in C++03 mode. #include <stdint.h> #include <boost/container/vector.hpp> struct data { int i_; boost::container::vector<data> v_; }; int main( int argc, char** argv ) { data myData; myData.i_ = 10; data myData2; myData2.i_ = 30; myData.v_.push_back( myData2 ); return 0; } It compiles successfully with g++ --std=c++0x test-cont.cpp However if I remove the --std=c++0x I get the following errors: g++ test-cont.cpp In file included from include/c++/4.4.6/memory:49, boost/container/container_fwd.hpp:36, boost/container/vector.hpp:20, from test-cont.cpp:2: include/c++/4.4.6/bits/stl_algobase.h: In static member function static _OI std::__copy_move<false, false, std::random_access_iterator_tag>:: __copy_m(_II, _II, _OI) [with _II = boost::container::constant_iterator<data, long int>, _OI = data*]: include/c++/4.4.6/bits/stl_algobase.h:397: instantiated from _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false, _II = boost::container::constant_iterator<data, long int>, _OI = data*] include/c++/4.4.6/bits/stl_algobase.h:436: instantiated from _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false, _II = boost::container::constant_iterator<data, long int>, _OI = data*] include/c++/4.4.6/bits/stl_algobase.h:468: instantiated from _OI std::copy(_II, _II, _OI) [with _II = boost::container::constant_iterator<data, long int>, _OI = data*] boost/move/move.hpp:1147: instantiated from boost::copy_or_move(I, I, F, typename boost::move_detail::disable_if< boost::move_detail::is_move_iterator, void>::type*) [with I = boost::container::constant_iterator<data, long int>, F = data*] boost/container/detail/advanced_insert_int.hpp:58: instantiated from void boost::container::container_detail::advanced_insert_aux_proxy<A, FwdIt, Iterator>::copy_remaining_to(Iterator) [with A = std::allocator<data>, FwdIt = boost::container::constant_iterator<data, long int>, Iterator = data*] test-cont.cpp:21: instantiated from here include/c++/4.4.6/bits/stl_algobase.h:343: error: no match for operator= in * __result = __first.boost::container::constant_iterator<T, Difference>::operator* [with T = data, Difference = long int]() test-cont.cpp:5: note: candidates are: data& data::operator=(data&) It looks like boost::container::vector requires move semantics which I assumed would automatically use boost::move when compiled with a c++03 compiler. If I manually modify the struct data to define: a default constructor a copy constructor an assignment operator an emulated move constructor using BOOST_RV_REF an emulated move assignment operator using BOOST_RV_REF The example compiles. Having to manually add these move/copy constructors and assignment operators for C++03 is laborious. Is this a bug with boost::container? -- View this message in context: http://boost.2283326.n4.nabble.com/boost-container-vector-fails-to-compile-… Sent from the Boost - Users mailing list archive at Nabble.com.

4 5

Visual Studio Debugger "renderer" support for Boost.Container ?
by John M. Dlugosz 29 Oct '12

29 Oct '12

MS Visual Studio's Debugger comes pre-loaded with "renderers" (I forget what S.T.L. actually called them) for the containers and smart pointers supplied with the compiler. Looking at a Boost Container in the debugger is not nearly so nice. Has anyone looked into adding renderers for them?

3 2