February 2013 - Boost-users

[PBGL] Bug? problem removing self loop in graph parallel
by bminano 28 Feb '13

28 Feb '13

Hello, I have a problem removing edges a graph in pbgl. There are concretely self loops. I think it could be a bug in the library, because for the monoprocessor library it works. I use remove_edge_if to delete the self-loops. The bgl code works ok, but the pbgl code does not. The problem occurs looking the in_egdes of the vertex 8. It detects that it have a in_edge from 8, but when looking for the out_edges of 8 it does not appears as expected. Maybe it is a misconfiguration, but i don't think so. I attached the monoprocessor code and the multiprocessor one if someone wants to look at them. Please, could someone help me? Thank you elimina_vertices.cpp <http://boost.2283326.n4.nabble.com/file/n4643588/elimina_vertices.cpp> elimina_vertices_mono.cpp <http://boost.2283326.n4.nabble.com/file/n4643588/elimina_vertices_mono.cpp> -- View this message in context: http://boost.2283326.n4.nabble.com/PBGL-Bug-problem-removing-self-loop-in-g… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

Adding indexes + serialization for MultiIndex
by Sohail Somani 28 Feb '13

28 Feb '13

I haven't actually happened upon this problem yet but I just want to know if I know how to deal with it for the future. My question is: how does the serialization work (or not work) if we add or remove indexes from the type? My suspicion is that one would have to do something like this: // version 1: BOOST_CLASS_VERSION(Thingy,1); typedef multi_index_container<thing,indexes> myset1_t; myset1_t m_MySet; ... template<typename Ar> void serialize(Ar & a, unsigned int) { ar & m_MySet; } // version 2 BOOST_CLASS_VERSION(Thingy,2); typedef multi_index_container<thing,indexes> myset1_t; typedef multi_index_container<thing,indexes2> myset2_t; myset2_t m_MySet; // using new version ... template<typename Ar> void serialize(Ar & a, unsigned int fv) { if(Ar::is_loading && fv == 1) { myset1_t set; ar & set; m_MySet.clear(); m_MySet.insert(m_MySet.begin(),set.begin(),set.end()); } else ar & m_MySet; } Would this be OK, errors in syntax aside? Thanks, Sohail

2 1

[Geometry] please help; using buffer() extensions
by John Lilley 28 Feb '13

28 Feb '13

(sorry another post; someone told me to put [library name] in [] in subject... learning something new every day :) Something of a repost, but I've learned a bit more on the path to being truly confused. It appears that boost\geometry\extensions\algorithms\buffer\buffer_inserter.hpp contains some specializations for buffering other shape types? But I'm out of my depth here... is there an example? What do I need to do in order to buffer: a point? A linestring? A vector of polygons? A heterogeneous collections of shapes? Is this generalization of buffer also going to work as a "deflate" for polygons? If someone can tell me "include these headers, use these algorithms", it will help a lot! Thanks John

2 7

[CONFIG] static const definitions
by John M. Dlugosz 28 Feb '13

28 Feb '13

I ran into a compiler idiosyncrasy, and my usual approach is to use the macros and mechanisms that Boost does in the same situation. But I can't find what I'm looking for in the Boost.Config documentation. So what does Boost do here? I found that the VS2010 compiler automatically defines a static const member that has been initialized inline in the declaration, and thus supplying a (required!) definition without the initializer at namespace or file scope will give a linker error if the class declaration is in a header that appears in more than one translation unit. At least one other compiler does in fact require the bare definition to link properly, and doesn't generate it automatically as an enhancement. So I need to make these definitions conditional based on the platform (and perhaps the exact compiler version? That's why I like to use the existing config knowledge base!) I see that Boost has BOOST_STATIC_CONSTANT but that is for compilers that don't have the in-class initialization at all. So if Boost is using such constructs, how does it deal with the linker idiosyncrasy?

4 4

Emplace for Boost heaps
by Rob Patro 27 Feb '13

27 Feb '13

Hi, I'm trying to use the emplace function for the Boost heaps. I've come up with a minimal example (attached), but when I compile it I get the following error: In file included from testpq.cpp:1:0: > > /opt/local/include/boost/heap/skew_heap.hpp: In instantiation of >> 'boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, A6>::node_pointer >> boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6>::emplace_internal(Args&& ...) [with Args = {int, int}; T = thing; A0 = >> boost::heap::compare<cmpthings>; A1 = boost::parameter::void_; A2 = >> boost::parameter::void_; A3 = boost::parameter::void_; A4 = >> boost::parameter::void_; A5 = boost::parameter::void_; A6 = >> boost::parameter::void_; boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6>::node_pointer = boost::heap::detail::skew_heap_node<thing, false>*]': > > /opt/local/include/boost/heap/skew_heap.hpp:769:13: required from >> 'static void boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6>::push_void::emplace(boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6>*, Args&& ...) [with Args = {int, int}; T = thing; A0 = >> boost::heap::compare<cmpthings>; A1 = boost::parameter::void_; A2 = >> boost::parameter::void_; A3 = boost::parameter::void_; A4 = >> boost::parameter::void_; A5 = boost::parameter::void_; A6 = >> boost::parameter::void_; boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6> = boost::heap::skew_heap<thing, boost::heap::compare<cmpthings> >]' > > /opt/local/include/boost/heap/skew_heap.hpp:437:70: required from >> 'typename boost::mpl::if_c<boost::heap::skew_heap<T, A0, A1, A2, A3, A4, >> A5, A6>::is_mutable, typename boost::mpl::if_c<boost::heap::skew_heap<T, >> A0, A1, A2, A3, A4, A5, A6>::is_mutable, typename boost::heap::skew_heap<T, >> A0, A1, A2, A3, A4, A5, A6>::implementation_defined::handle_type, >> void*>::type, void>::type boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6>::emplace(Args&& ...) [with Args = {int, int}; T = thing; A0 = >> boost::heap::compare<cmpthings>; A1 = boost::parameter::void_; A2 = >> boost::parameter::void_; A3 = boost::parameter::void_; A4 = >> boost::parameter::void_; A5 = boost::parameter::void_; A6 = >> boost::parameter::void_; typename >> boost::mpl::if_c<boost::heap::skew_heap<T, A0, A1, A2, A3, A4, A5, >> A6>::is_mutable, typename boost::mpl::if_c<boost::heap::skew_heap<T, A0, >> A1, A2, A3, A4, A5, A6>::is_mutable, typename boost::heap::skew_heap<T, A0, >> A1, A2, A3, A4, A5, A6>::implementation_defined::handle_type, void*>::type, >> void>::type = void]' > > testpq.cpp:27:20: required from here > > /opt/local/include/boost/heap/skew_heap.hpp:808:9: error: no matching >> function for call to 'boost::heap::skew_heap<thing, >> boost::heap::compare<cmpthings> >::make_node(int, int)' > > /opt/local/include/boost/heap/skew_heap.hpp:808:9: note: candidates are: > > In file included from /opt/local/include/boost/heap/skew_heap.hpp:21:0, > > from testpq.cpp:1: > > /opt/local/include/boost/heap/detail/stable_heap.hpp:189:19: note: >> boost::heap::detail::heap_base<T, Cmp, constant_time_size, >> StabilityCounterType, stable>::internal_type >> boost::heap::detail::heap_base<T, Cmp, constant_time_size, >> StabilityCounterType, stable>::make_node(const T&) [with T = thing; Cmp = >> cmpthings; bool constant_time_size = true; StabilityCounterType = long >> unsigned int; bool stable = false; boost::heap::detail::heap_base<T, Cmp, >> constant_time_size, StabilityCounterType, stable>::internal_type = thing] > > /opt/local/include/boost/heap/detail/stable_heap.hpp:189:19: note: >> candidate expects 1 argument, 2 provided > > /opt/local/include/boost/heap/detail/stable_heap.hpp:195:10: note: T&& >> boost::heap::detail::heap_base<T, Cmp, constant_time_size, >> StabilityCounterType, stable>::make_node(T&&) [with T = thing; Cmp = >> cmpthings; bool constant_time_size = true; StabilityCounterType = long >> unsigned int; bool stable = false] > > /opt/local/include/boost/heap/detail/stable_heap.hpp:195:10: note: >> candidate expects 1 argument, 2 provided > > It seems that something is amiss with the perfect forwarding (or I'm somehow using emplace incorrectly). Either way, any help getting this to work or figuring out why it doesn't would be greatly appreciated. Thanks, Rob

1 0

Fwd: Boost.Locale - Help linking to ICU static libraries please
by Brad Keifenheim 27 Feb '13

27 Feb '13

Hello, I'm building Boost 1.53.0 on FreeBSD using GCC. I wish to provide the ICU back-end to Boost.Locale using the static implementation only. This is the command line I used to configure and build ICU 49.1.2: runConfigureICU FreeBSD --prefix=/3rdParty/icu4c/release --bindir=/3rdParty/icu4c/release/bin64 --sbindir=/3rdParty/icu4c/release/sbin64 --libdir=/3rdParty/icu4c/release/lib64 --enable-static=yes --enable-shared=no --with-library-bits=64 CPPFLAGS=-DU_TIMEZONE=0 The DU_TIMEZONE flag is a workaround for ICU on FreeBSD for that particular version. For this discussion it may safely be ignored. The ICU build results as follows: /3rdParty/icu4c/release |_ bin64 |_ include |_ lib64 |_ sbin64 |_ share As intended, the shared (*.so) libraries are not built. Only static (*.a) libraries are present in lib64: libsicudata.a, libsicui18n.a, libsicuio.a, etc... I then attempt the following command to build Boost: b2 toolset=gcc link=static variant=release threading=multi address-model=64 --build-dir=obj --stagedir=bin/64 --without-python -sICU_PATH=/3rdParty/icu4c/release/ --layout=versioned -a -j8 With this setup the build reports as follows: *...* * * *Performing configuration checks* * * * - x86 : yes* * - has_icu builds : no* *warning: Graph library does not contain MPI-based parallel components.* *note: to enable them, add "using mpi ;" to your user-config.jam* * - iconv (libc) : no* * - iconv (separate) : no* * - icu : no* * - icu (lib64) : no* *- Boost.Locale needs either iconv or ICU library to be built.* * * *...* I do not have this problem when -sICU_PATH points to a directory containing the shared versions of the ICU libraries: libicudata.so, libicui18n.so, libicuio.so ... Unfortunately the constraints of the end product restrict me from delivering ICU as a shared library. Will Boost.Locale accept the ICU back-end as a static library implementation? If so, what have I configured improperly? Thank you in advance for your assistance. Brad

1 0

[CONFIG] static const definitions
by John M. Dlugosz 27 Feb '13

27 Feb '13

On 2/27/2013 1:23 PM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote: > Exactly, hence my suggestion for performing a preprocessor check > around the out-of-line definition. I suppose it would be nice to have > a BOOST-y preprocessor def that could let you know if this is the > case... OK, now we're getting somewhere. You understand that this is exactly what I _am_ doing. My questions is, how does Boost determine which compilers in which it should withhold the definition? Do you know of an example of one someplace?

2 1

[CONFIG] static const definitions
by John M. Dlugosz 27 Feb '13

27 Feb '13

On 2/27/2013 10:35 AM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote: > ...and then we use preprocessor checks to decide whether or > not to provide definitions in a cop [cpp?] file. It is best to provide them for > gcc, but not for msvc 2010 for example. Yes, exactly. So what macro does CONFIG provide to determine whether they should be present or absent?

1 0

Re: [Boost-users] Boost.MSM cc1plus.exe:: error: out of memory allocating 65532
by degoah 27 Feb '13

27 Feb '13

Hi Christophe, I will check the thing with the cstor. FYI: my library that uses the boost.msm-based state machine mechanism shall be released as shared library. It is used to realize Remote Procedure Calls. So my library consists of one Master state machine (which consists of 5 submachines and together 21 states) and one Slave state machine (which consists of 4 submachines and 19 states). The user application linking against my library has the possibility to choose if the slave state machine or the master state machine part shall be used. Now the problem could be, that I use a boost::variant type to store the 44 different application event types. This variant type I pass to the process_event method of each state machine (master and slave) although the slave state machine doesn't support the same event types like the master and vice-versa. This produces unnecessary template invocations and memory allocation. So the solution could be, to split my single shared library into two shared libraries: one for the master and one for the slave logic and each of it has a reduced boost::variant type( just with the event types of the concrete state machine). Or I keep the solution with the single shared library and I split the single boost::variant type into two different ones: one for the master and one for the slave state machine. And each boost::variant type will just be forwarded to the appropriate process_event method of the corresponding state machine. Doing so, will also prevent unnecessary template invocations for each event type on the corresponding state machine. Maybe this will also reduce the memory consumption... What is your opinion about this two putative solutions? Best regards (viele grüsse), Rafael Christophe Henry <christophe.j.henry(a)googlemail.com> schrieb: ----- Original Message ----- From: "RaRi" <degoah(a)gmx.de> Newsgroups: gmane.comp.lib.boost.user To: <boost-users(a)lists.boost.org> Sent: Wednesday, February 27, 2013 6:44 PM Subject: Re: Boost.MSM cc1plus.exe:: error: out of memoryallocating 65532 > Thank you all so far, > > I will investigate, how I can simplify my state machine and reduce the > number of events. > > Damn, I spent 1 month on that machine and now I have to change it... > > On linux there is no problem with that. Okay, the memory exceeds 1 GB > while > compiling my boost.msm based library. But it works fine! > > The problem what remains is to compile the stuff for windows. > > I have already just test one thing: Cross-compilation of my boost.Msm > state > machine on linux for windows with mingw32msvc-g++. But already doing this > produced some errors: > > *../src/TransportLayer/Statemachine/Master/CStateMasterHandshaking.hpp:33: > error: class ‘CStateMasterHandshaking_’ does not have any field named > ‘BaseStateMachineFrontEnd’ > ../src/TransportLayer/Statemachine/Master/CStateMasterHandshaking.hpp:33: > error: no matching function for call to > ‘BaseStateMachineFrontEnd<CStateMasterHandshaking_>::BaseStateMachineFrontEnd()’ > ../src/TransportLayer/Statemachine/Master/../Common/BaseStateMachineFrontEnd.hpp:48: > note: candidates are: > BaseStateMachineFrontEnd<TYPE>::BaseStateMachineFrontEnd(EventQueue&) > [with > TYPE = CStateMasterHandshaking_] > ../src/TransportLayer/Statemachine/Master/../Common/BaseStateMachineFrontEnd.hpp:26: > note: > BaseStateMachineFrontEnd<CStateMasterHandshaking_>::BaseStateMachineFrontEnd(const > BaseStateMachineFrontEnd<CStateMasterHandshaking_>&)* > > I think, the MSVC-specific cross compiler is responsible for this error. > > I don't now, how to continue with this problem. At the worst I have to > change the state machine completely..... > > Thanks so far, > > Rafael Hi, not sure how to help you there without code, but from what I see, I'd say that BaseStateMachineFrontEnd has a ctor which hides the default-ctor. Try to provide one and see if that helps. I don't think you have to change it completely. Probably replacing a bunch of events by a single one containing an id as attribute, then checking it in a guard to see what event you really posted would probably be enough. Cheers, Christophe _____________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [parallel graph] error building parallel BGL
by The Maschine 27 Feb '13

27 Feb '13

Yes I have that. What I did is first build the full build and then try to build the example with the line you gave me. I did something like this: ➜ boost-trunk ./b2 threading=multi Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - has_icu builds : no - gcc visibility : yes - long double support : yes Building the Boost C++ Libraries. error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no Component configuration: - atomic : building - chrono : building - context : building - coroutine : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building ^C ➜ boost-trunk

2 1