March 2012 - Boost - lists.preview.boost.org

Using an element of a class A in a constructor of a class B (reflection with boost::python)
by christophe jean-joseph 07 Mar '12

07 Mar '12

Hello everyone, The situation is as follow. I have a C++ code that I haven't written and that I barely can modified. I am supposed to reflect this code in Python with boost. In the code, I have something looking like this: Class A_Base { A_Base(){}; ~A_Base(){}; Whatever virtual and pure virtual functions; } Class A_Derived{ A_Derived(Type1 arg1,...){whatever instructions;} ~A_Derived(){}; Whatever functions; } Class B { B(A_Base& aBase, double& x){}; ~B(){}; Whatever functions; } In the C++ main, at some point aDerived A_Derived is set, and then B(aDerived, x). I need to reflect that under python. Until now, I have been able, with a simple example, to reflect a function f, which is not a ctor, from a class B using A_Base& as argument type, but I can't figure out how to deal with it for a constructor. Based on: http://wiki.python.org/moin/boost.python/ExportingClasses I am declaring f under both its class B and A_Base as follow: .def("f", &B::f) But when I try this for a constructor as f, it refuse to compile. Anyone got a clue? Thank you very much in advance for any further help.

1 0

[move] [container] [unordered] version 1.49.0 and gcc 3.4.3
by Burt, David 07 Mar '12

07 Mar '12

Dear all I am trying to use boost on the LynxOS-SE 5.0.0 operating system. This has gcc 3.4.3 as the tool chain. To validate the library I am running the regression tests. Previously we have used boost 1.39.0 with some minor patches, 1.49.0 has required fewer patches. However I am stuck with the following problem, if someone could suggest a workaround or identify a patch to the toolchain that I can request to be included by LynuxWorks it would be very much appreciated. The technique used by the move, container & unordered libraries to generate specific implementations of methods based on type characteristics does not work on this compiler. I have included the compiler output from one of the tests. Both of the methods defined in move_helpers are generated for the push_back method even though they should be mutually exclusive and one of them should not be generated based on the SFINAE principal. Thanks David. move - move_algorithm - gcc-lynx Compiler output: ../boost/container/vector.hpp: In instantiation of `boost::container::vector<movable, std::allocator<movable> >': ../libs/move/test/move_algorithm.cpp:19: instantiated from here ../boost/container/vector.hpp:996: error: `template<class BOOST_MOVE_TEMPL_PARAM> typename boost::enable_if_c<(((! boost::is_class<BOOST_MOVE_TEMPL_PARAM>::value) || (! boost::move_detail::is_rv<BOOST_MOVE_TEMPL_PARAM>::value)) && (! boost::is_same<T,BOOST_MOVE_TEMPL_PARAM>::value)), void>::type boost::container::vector::push_back(const BOOST_MOVE_TEMPL_PARAM&) [with BOOST_MOVE_TEMPL_PARAM = BOOST_MOVE_TEMPL_PARAM, T = movable, A = std::allocator<movable>]' and `template<class BOOST_MOVE_TEMPL_PARAM> typename boost::enable_if_c<(( boost::is_class<T>::value && boost::is_same<T,BOOST_MOVE_TEMPL_PARAM>::value) && (! boost::has_move_emulation_enabled<BOOST_MOVE_TEMPL_PARAM>::value)), void>::type boost::container::vector::push_back(const BOOST_MOVE_TEMPL_PARAM&) [with BOOST_MOVE_TEMPL_PARAM = BOOST_MOVE_TEMPL_PARAM, T = movable, A = std::allocator<movable>]' cannot be overloaded ../boost/container/vector.hpp:1117: error: `template<class BOOST_MOVE_TEMPL_PARAM> typename boost::enable_if_c<(((! boost::is_class<BOOST_MOVE_TEMPL_PARAM>::value) || (! boost::move_detail::is_rv<BOOST_MOVE_TEMPL_PARAM>::value)) && (! boost::is_same<T,BOOST_MOVE_TEMPL_PARAM>::value)), boost::container::container_detail::vector_iterator<typename boost::container::allocator_traits<A>::pointer> >::type boost::container::vector::insert(boost::container::container_detail::vector_const_iterator<typename boost::container::allocator_traits<A>::pointer>, const BOOST_MOVE_TEMPL_PARAM&) [with BOOST_MOVE_TEMPL_PARAM = BOOST_MOVE_TEMPL_PARAM, T = movable, A = std::allocator<movable>]' and `template<class BOOST_MOVE_TEMPL_PARAM> typename boost::enable_if_c<(( boost::is_class<T>::value && boost::is_same<T,BOOST_MOVE_TEMPL_PARAM>::value) && (! boost::has_move_emulation_enabled<BOOST_MOVE_TEMPL_PARAM>::value)), boost::container::container_detail::vector_iterator<typename boost::container::allocator_traits<A>::pointer> >::type boost::container::vector::insert(boost::container::container_detail::vector_const_iterator<typename boost::container::allocator_traits<A>::pointer>, const BOOST_MOVE_TEMPL_PARAM&) [with BOOST_MOVE_TEMPL_PARAM = BOOST_MOVE_TEMPL_PARAM, T = movable, A = std::allocator<movable>]' cannot be overloaded ________________________________ Please consider the environment before printing this e-mail. The contents of this e-mail message (including any attachments) are confidential to and are intended to be conveyed for the use of the recipient to whom it is addressed only. If you receive this transmission in error, please notify the sender of this immediately and delete the message from your system. Any distribution, reproduction or use of this message by someone other than recipient is not authorized and may be unlawful.

1 0

Shit. Looks like I broke something
by Marshall Clow 07 Mar '12

07 Mar '12

When I run the status tests; I get the following error [ Revision 77175; gcc 4.2.1; Mac OS X 10.7.3; toolset darwin ] > cd $BOOST/trunk/status > ../b2 > MPI auto-detection failed: unknown wrapper compiler mpic++ > Please report this error to the Boost mailing list: http://www.boost.org > You will need to manually configure MPI support. > Performing configuration checks > > - has_icu builds : no > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:604: in object(main-target)(a)26280.add-alternative from module object(main-target)@26280 > error: default build must be identical in all alternatives > error: main target is ../libs/context/build/asm_context_sources > error: with > error: differing from previous default build <toolset>darwin > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:482: in build-main-targets from module object(project-target)@192 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:332: in main-target from module object(project-target)@192 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:397: in find-really from module object(project-target)@192 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:435: in object(project-target)(a)192.find from module object(project-target)@192 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:373: in find-really from module object(project-target)@2522 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:435: in object(project-target)(a)2522.find from module object(project-target)@2522 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:816: in resolve-reference from module targets > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:833: in targets.generate-from-reference from module targets > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:1217: in generate-dependencies from module object(alias-target-class)@2529 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:1266: in object(alias-target-class)(a)2529.generate from module object(alias-target-class)@2529 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:732: in generate-really from module object(main-target)@26276 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:704: in object(main-target)(a)26276.generate from module object(main-target)@26276 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:258: in object(project-target)(a)2522.generate from module object(project-target)@2522 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build/targets.jam:258: in object(project-target)(a)827.generate from module object(project-target)@827 > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/build-system.jam:736: in load from module build-system > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/kernel/modules.jam:283: in import from module modules > /Volumes/EyeFive/Marshall/Sources/boost/trunk/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module > /Volumes/EyeFive/Marshall/Sources/boost/trunk/boost-build.jam:17: in module scope from module I was building fine; I checked in r77115, which was a bunch of changes in libs/config/test; ran the tests there, all was well. Then I tried a full regression test, and got this. Maybe it was the other changes that were made to build (77190/91/92/93), but they look benign to me. Suggestions on the best way to debug this? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 13

Re: [boost] [Boost-commit] svn:boost r77194 - in trunk: boost/config boost/config/compiler boost/config/stdlib libs/config/doc/html/boost_config libs/config/test libs/config/test/all
by Michel Morin 07 Mar '12

07 Mar '12

Hi Marshall, > Author: marshall > Date: 2012-03-03 22:00:49 EST (Sat, 03 Mar 2012) > New Revision: 77194 > […] > --- /trunk/libs/config/test/boost_no_0x_hdr_array.ipp (original) > +++ trunk/libs/config/test/boost_no_cxx11_hdr_array.ipp 2012-03-03 22:00:49 EST (Sat, 03 Mar 2012) > […] > -namespace boost_no_0x_hdr_array { > +namespace boost_no_0cxx11_hdr_array { `boost_no_0cxx11_hdr_array` should be `boost_no_cxx11_hdr_array` ;) Regards, Michel

2 1

[numeric] Applying trivial bugfix
by Antony Polukhin 06 Mar '12

06 Mar '12

Hi, There are a lot of feature requests to support compilation with disabled exceptions #5731, #5076, #5393, #5800. Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Can I apply another trivial fix: struct def_overflow_handler { void operator() ( range_check_result r ) // throw(negative_overflow,positive_overflow) { #ifndef BOOST_NO_EXCEPTIONS if ( r == cNegOverflow ) throw negative_overflow() ; else if ( r == cPosOverflow ) throw positive_overflow() ; #else if ( r == cNegOverflow ) ::boost::throw_exception(negative_overflow()) ; else if ( r == cPosOverflow ) ::boost::throw_exception(positive_overflow()) ; #endif } } ; Adding this will fix all the tickets and allow some of the dependent libraries to build with disabled exceptions. Boost.Lexical_cast tests will cover Boost.Numeric usage cases with disabled exceptions. Best regards, Antony Polukhin

4 7

[msm]omitting region id at the entry pseudo state
by Takatoshi Kondo 05 Mar '12

05 Mar '12

Hello, Now, I'm using Boost.Msm (Version1.49.0). I have a question about a transition behavior when I omit a region id at the entry pseudo state. The document said that when we use the explicit entry, if the state machine satisfied the conditions below, we can omit the region id. http://www.boost.org/doc/libs/1_49_0/libs/msm/doc/HTML/ch03s02.html#d0e852 " Thanks to the mpl_graph library you can also omit to provide the region index and let MSM find out for you. The are however two points to note: - MSM can only find out the region index if the explicit entry state is somehow connected to an initial state through a transition, no matter the direction. - There is a compile-time cost for this feature. " Because of the discussion below, I believe that this rule can also be applied to entry pseudo states. http://boost.2283326.n4.nabble.com/msm-how-to-distinguish-region-ids-tt3612… However, when I omitted the region id, the state machine transitioned to the SubState1. struct Entry1:msmf::entry_pseudo_state<> {}; If I provided the region id, the state machine transitioned to the SubState2. struct Entry1:msmf::entry_pseudo_state<0> {}; See entry_pt_omit_rid.cpp (Attached file) As far as I can understand, Entry1 and SubState1, initial_state, are connected. (See fig.png) Is there any reason that I can't omit the region id in this case? Thanks, Takatoshi

2 3

[Thread] Dll Plugin depending from boost thread
by Keraval Yannick 05 Mar '12

05 Mar '12

Hi guys, An application developed in my company uses the concept of "plugin" which relies on the use of DLL (windows 7 box, Visual Studio 2005). We are using Boost v 1.43 and when loading a plugin with a call to LoadLibrary, application asserts with the following message Debug Assertion Failed! Program: C:\Windows\system32\regsvr32.exe File: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dllinit.cpp Line: 587 --> ASSERT(AfxGetModuleState() != AfxGetAppModuleState()); We could point out that this is due to the use of the boost thread library. A quick google search pointed us to an issue in the Boost.Thread library (e.g. http://stackoverflow.com/questions/5355931/adding-include-boost-thread-mutex -hpp-breaks-my-activex-control). One proposed solution is to build a DLL instead of a static lib but this is impossible in our company (only plugin can be compiled as dll). We also try to update boost to V1.49 but the debug assertion is still raised. Is there another way to fix this ? We could not find any ticket related to this problem (neither in the opened tickets nor in the closed tickets), is this behavior considered as normal ? Thanks -- View this message in context: http://boost.2283326.n4.nabble.com/Thread-Dll-Plugin-depending-from-boost-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Parts of linkflags are disappearing: $ISALIST gone
by Maciej (Matchek) Bliziński 05 Mar '12

05 Mar '12

My linkflags setting involves a dollar sign: linkflags='-R/opt/csw/lib/$ISALIST' The $ISALIST dynamic token tells the linker to iterate through supported instruction sets and pick the best one[1]. When the Boost binaries are built, the RPATH in the binaries is missing the dollar sign and everything after it: $ /usr/ccs/bin/dump -Lv work/solaris10-sparc/pkgroot/opt/csw/gxx/lib/sparcv9/libboost_iostreams.so.1.49.0 | grep RPATH [13] RPATH /opt/csw/lib/64:/opt/csw/gxx/lib/:/opt/csw/gxx/lib/64:/opt/csw/lib/ Do you see the /opt/csw/lib/ bit with the slash at the end? It could be explained by the contents of linkflags being interpolated by a shell. In my build, it's important to pass the dollar sign unchanged. Here's an example of correctly set RPATH: /usr/ccs/bin/dump -Lv /opt/csw/lib/libz.so.1 | grep RPATH [6] RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib I need to pass the same flag to Boost libraries. Has anyone else seen this problem? Maciej [1] http://docs.oracle.com/cd/E19082-01/819-0690/appendixc-3/index.html

1 0

[context] Providing template class enumerate in context.hpp
by Julien Nitard 04 Mar '12

04 Mar '12

Hi all, I am trying to use the newly accepted boost.context and I am wondering why something as useful as the template enumerate is not diretly given when including "context.hpp" and not even in a separate header. Since it's in the doc it would be a good addition IMHO. Thanks, Julien PS: the link to boost.context doc is broken and the git repos seems to have moved.

5 14

bug in gcc.jam
by Oliver Kowalke 04 Mar '12

04 Mar '12

Hello, gcc.jam:451 applies always -m32 for 32bit systems. In the case of ARM architecture this is false because gcc on arm does not recognize -m32. In order to correct this issue I need to know how to test for ARM architecture at this code line (sorry I'm not that boost.build expert). Oliver

1 0