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

[exception,serialization] transporting exceptions
by Brian Budge 05 Oct '12

05 Oct '12

Hi all - I like that boost::exception provides a mechanism to copy exceptions. This can be used to transport an exception across thread boundaries, which is nice. I'm running a program that can optionally start nodes using MPI to do back-end computations. I'd like to be able to "copy" the exception from one node to another. Are there any existing tools for something like a serialization of these kinds of exceptions? In non-MPI mode, I'd like to transport the exception across thread boundaries, pass it through some functions (causing actions to be taken along the way), and then finally to rethrow the exception. In MPI mode I want all of that PLUS, in place of one of the function calls, I'd like to transport the exception across MPI in some way. Are there any semi-automatic tools already in existence that will get me this (or close)? Or do I need to implement boost serialization for my entire exception hierarchy? If I do the latter, it seems I will need to operator new the exception, and will not easily be able to know when I can delete in a catch? Thanks, Brian

2 3

Trouble w/ fruchterman-reingold
by eric 05 Oct '12

05 Oct '12

I'm seeing a weird problem in fruchterman_reingold.hpp that after the displacements are calculated for every vertex, it gets down to the loop where it updates the positions (starting on line 327), and all the displacements are (0,0) by that point (they had been sensible values up in the calculation loop). Any idea what I could be doing to cause that? Here is my code: struct spring_attractive_force { template<typename Graph, typename T> T operator()(typename graph_traits<Graph>::edge_descriptor, T k, T d, const Graph&) const { return d; } }; struct magnetic_repulsive_force { template<typename Graph, typename T> T operator()(typename graph_traits<Graph>::vertex_descriptor, typename graph_traits<Graph>::vertex_descriptor, T k, T d, const Graph&) const { return 1 / (d * d); } }; typedef adjacency_list<listS, listS, undirectedS, // Vertex properties property<vertex_index_t, int, property<vertex_position_t, point> >, // Edge properties property<edge_weight_t, double> > Graph; enum {A, B, C, D, E, F, G, H}; simple_edge triangular_edges[14] = { {A, B}, {B, C}, {C, A}, {D, E}, {E, F}, {F, G}, {G, H}, {H, D}, {D, F}, {F, H}, {H, E}, {E, G}, {G, D} }; Graph g(&triangular_edges[0], &triangular_edges[13], 8); // Generate (x,y) coordinates for every node // - Randomly layout vertices of graph minstd_rand gen; rectangle_topology<> rect_top(gen, -25, -25, 25, 25); random_graph_layout(g, get(vertex_position, g), rect_top); // - Run Fruchterman Reingold algorithm on them typedef square_topology<> Topology; Topology topology(gen, 50.0); fruchterman_reingold_force_directed_layout(g, get(vertex_position, g), topology, attractive_force(spring_attractive_force()). repulsive_force(magnetic_repulsive_force()). force_pairs(all_force_pairs()). cooling(linear_cooling<double>(100))); -- View this message in context: http://boost.2283326.n4.nabble.com/Trouble-w-fruchterman-reingold-tp4636494… Sent from the Boost - Users mailing list archive at Nabble.com.

2 13

link errors with boost serialization
by xavier 05 Oct '12

05 Oct '12

I have just built boost_1_51_1 with no problems on linux redhat 5.5 64-bit machine However, when i try to link a program that uses the g++ client_test.o -rdynamic -L/opt/boost_1_51_0/stage/lib -lboost_serialization -lboost_wserialization -o client_test it gives the following error: client_test.o: In function `boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::extended_type_info_typeid_1()': client_test.cpp:(.text._ZN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionEC1Ev[boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::extended_type_info_typeid_1()]+0x12): undefined reference to `boost::serialization::detail::extended_type_info_typeid_0::extended_type_info_typeid_0()' client_test.cpp:(.text._ZN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionEC1Ev[boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::extended_type_info_typeid_1()]+0x27): undefined reference to `boost::serialization::extended_type_info::self_register()' client_test.cpp:(.text._ZN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionEC1Ev[boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::extended_type_info_typeid_1()]+0x3a): undefined reference to `boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0()' client_test.o: In function `boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::~extended_type_info_typeid_1()': client_test.cpp:(.text._ZN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionED0Ev[boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::~extended_type_info_typeid_1()]+0x1d): undefined reference to `boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0()' client_test.o: In function `boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::~extended_type_info_typeid_1()': client_test.cpp:(.text._ZN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionED1Ev[boost::serialization::detail::extended_type_info_typeid_1<gps_position const>::~extended_type_info_typeid_1()]+0x1d): undefined reference to `boost::serialization::detail::extended_type_info_typeid_0::~extended_type_info_typeid_0()' client_test.o:(.rodata._ZTVN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionEE[vtable for boost::serialization::detail::extended_type_info_typeid_1<gps_position const>]+0x10): undefined reference to `boost::serialization::detail::extended_type_info_typeid_0::less_than(boost::serialization::extended_type_info const&) const' client_test.o:(.rodata._ZTIN5boost13serialization6detail27extended_type_info_typeid_1IK12gps_positionEE[typeinfo for boost::serialization::detail::extended_type_info_typeid_1<gps_position const>]+0x10): undefined reference to `typeinfo for boost::serialization::detail::extended_type_info_typeid_0 What could be causing the problem ? -- View this message in context: http://boost.2283326.n4.nabble.com/link-errors-with-boost-serialization-tp4… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

Boost TraitsType Question
by Rawate, Vishal CIV NAVAIR-WD-5-2-7-1-1-0-E., 527110E 04 Oct '12

04 Oct '12

Hello, I am writing a function using templates in C++.I want to find the type of variable that is being to the function. I was wondering if I could use the Boost TypeTraits library or is there another library that I can use. I would highly appreciate any help. Thanking in advance. Vishal CodeSnipet: Template<typename T> Void setTag(T myVariable) { If(T == short) { Do something; } If(T == long) { Do something; } }

4 5

[Review Report] ODEInt accepted
by Steven Watanabe 04 Oct '12

04 Oct '12

AMDG The review of the ODEInt library submitted by Mario Mulansky and Karsten Ahnert ended last Friday. Many thanks to everyone who participated in this review. The library is ACCEPTED into Boost unconditionally. Summary: 7 ACCEPT 1 ABSTAIN Reviews: http://lists.boost.org/Archives/boost/2012/09/196733.php http://lists.boost.org/Archives/boost/2012/09/196882.php http://lists.boost.org/Archives/boost/2012/09/196883.php http://lists.boost.org/Archives/boost/2012/10/196966.php http://lists.boost.org/Archives/boost/2012/10/196965.php http://lists.boost.org/boost-users/2012/09/76089.php http://lists.boost.org/boost-users/2012/09/76058.php http://lists.boost.org/boost-users/2012/09/76069.php Other comments: http://lists.boost.org/Archives/boost/2012/09/196756.php The reviews were overwhelmingly positive. Most reviewers were satisfied with the library documentation and interfaces. Issues: These were points brought up by reviewers. The authors are free to accept or reject any of these at their discretion. - A number of minor documentation corrections. - Automatically deduce the correct algebra from the state type. - Use a default initial step size. - Allow breaking out of the algorithms In Christ, Steven Watanabe

2 1

Re: [Boost-users] [odeint] Can odeint integrate a 2-dimensional function?
by Karsten Ahnert 04 Oct '12

04 Oct '12

On 10/04/2012 03:28 PM, Rob Conde wrote: > Say I have an equation that is a function of x and y...can I use odeint to > integrate this function over a 2-d region (i.e. a square or a circle, etc.)? > If so, are there any examples of this? I don't think this is possible. This sound like integration of a known function. Odeint is devoted to solve ordinary differential equations. Karsten

2 1

[process] how to suggest bugs/fixes for boost.process?
by Brian Budge 04 Oct '12

04 Oct '12

Hi all - I've started using boost.process despite the fact that it is not an official boost library. I've founds some cases that don't compile or give warnings, and I'd like to log a bug with possible fixes somewhere. Given that the library is not officially in boost, how should I go about this? Thanks, Brian

3 2

Moving an std::string into a boost::thread in C++03
by Adi Shavit 04 Oct '12

04 Oct '12

Hi, I'm using boost 1.51 on multiple platforms and compilers without C++11. In my main thread, I have a very long, expensive to copy, std::string veryLongString, that I need to pass to a new thread for processing. After the new thread is created I have no more use for veryLongString, hence I'd like to *move *it into the boost::thread ctor. Obviously, if veryLongString was created as a shared_ptr<std::string> then I could just *copy* the shared_ptr into the thread ctor, but it wasn't, so I'd need to copy it anyway. How can I [boost::]move() veryLongString into the boost::thread ctor (probably using via boost::bind)? Is this possible? Thanks, Adi

3 3

Re: [Boost-users] [asio] Custom asynchronous service
by Marat Abrarov 04 Oct '12

04 Oct '12

Hi Acer, > I would like to adapt my class to asio for offering > async_do_something(param, callback) interfaces. http://sourceforge.net/projects/asio-samples/ especially (SVN): https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk/include… https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk/include… or https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk/include… https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk/include… > After reading examples presented in asio/examples/services/ and some asio > source code. > > I found the example does not do invoke callback stuff (e.g. > asio/examples/service/logger_service.cpp). > > In case of asio source code, there are classes such as > detail::wait_handler<> that wrap user callbacks for invoked later. It's not a wrapper for deferred invocation. Here's my implementation of handler parking (Asio custom memory allocation and custom invocation strategy are supported): https://asio-samples.svn.sourceforge.net/svnroot/asio-samples/trunk/include… Regards, Marat Abrarov.

1 0

[BGL] vecS for vertex container and vertex index adjustments
by Sergey Mitsyn 03 Oct '12

03 Oct '12

Hi all, I know that while using vecS for vertices one has no vertex iterator stability upon removing vertices. But I have a question if there exists something like vertex _index_ stability. The documentation says that indices for vertices are automatically adjusted so that they are still in contiguous range, but it is not specified how it is done. Is it okay to assume that if a vertex with an index I is removed, then vertices with indices < I have their indices unchanged, while vertices with indices > I have their indices decreased by one? The actual problem is removing all vertices meeting some condition. Is the following code ok? // traverse all vertices and remove those for which predicate // condition_to_remove_vertex returns true. // graph is adjacency_list<.., vecS, ...> vertex_iterator vi = vertices(graph).first, vi_end = vertices(graph).second; while (vi != vi_end) { if (condition_to_remove_vertex(vi, graph)) { vertices_size_type end_index = vertex_index[*vi_end] , vi_index = vertex_index[*vi]; remove_vertex_f(*vi, graph); // vi and vi_end are invalid --end_index; vi = vertices(graph).first + vi_index; vi_end = vertices(graph).first + end_index; // now vi and vi_end are valid again } else ++vi; } This way seems to be more effective than to start iteration again every time a vertex is removed. ------------ Sergey Mitsyn.

3 14