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

[multi_array] Support for begin( ) & end( )?
by Robert Jones 08 Oct '08

08 Oct '08

Does multi_array support begin( ) & end( ) methods? If so what are their semantics? Does the returned iterator iterate over the first subscript, or over the whole container, or something else? Thanks - Rob.

2 2

[release mgt] Eric Niebler joining release management team
by Beman Dawes 08 Oct '08

08 Oct '08

Eric Niebler is joining the release management team. Eric will be helping out with general release management and quality control. Like Rene Rivera and Daniel James, he will backup Beman so that release management isn't dependent on any single person. Thanks to Eric for agreeing to help out! --Beman

1 0

[Graph] Two issues: Incorrect behavior with Prim's MST algorithm and Fruchterman-Reingold layout
by David Gleich 08 Oct '08

08 Oct '08

Hi, There are two issues in this note. Sorry for bundling them, but they both deal with incorrect behavior when the graph has self-loops. First issue: I found an problem with Prim's minimum spanning tree algorithm and graphs with self-loops. I looked through the documentation for the function and didn't see any notes about self-loops (which can cause the problem). The program at the end of this message doesn't produce a complete spanning tree on a connected graph, but it should. This issue shows up with any graph where a vertex has a self-loop with a lower weight than any of the other edges from that vertex. The cause of the issue is the relax function used in Dijkstra's algorithm. When computing a spanning tree, it shouldn't compare on self-loops. When used with the combine function for Prim's algorithm, it'll always pick out these self-loops. I'd love to see this issue fixed so I don't have to special case calls to Prim's algorithm to make sure all self-loops aren't there. The only way I see to do it is to make a special version of the Dijkstra code for Prim's algorithm. (It feels like the ramifications of changing relax.hpp could be considerably greater.) One possibility for a better fix is make a new version of Dijkstra's algorithm where the relax function is a template parameter. Prim's algorithm can then replace the entire relax behavior to get the behavior it needs. Second issue: The fruchterman_reingold_force_directed_layout function will always divide by 0 when computing the layout of a graph with self-loops. This issue has a rather simple fix. --- lib/boost_trunk/boost/graph/fruchterman_reingold.hpp +++ matlab-bgl/work/libmbgl/yasmic/boost_mod/fruchterman_reingold.hpp @@ -284,6 +284,9 @@ for (tie(e, e_end) = edges(g); e != e_end; ++e) { vertex_descriptor v = source(*e, g); vertex_descriptor u = target(*e, g); + if (v == u) { + continue; // self-loops should have no effect on the layout + } Dim delta_x = position[v].x - position[u].x; Dim delta_y = position[v].y - position[u].y; Dim dist = sqrt(delta_x * delta_x + delta_y * delta_y); Please let me know if there are any questions about these issues. Thanks, David Gleich /* tested with g++ 4.2 and boost 1.36.0 */ #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> #include <vector> #include <boost/graph/prim_minimum_spanning_tree.hpp> using namespace boost; using namespace std; int main(int argc, char** argv) { typedef adjacency_list < vecS, vecS, undirectedS, property<vertex_distance_t, int>, property < edge_weight_t, double > > graph; graph g(3); property_map<graph, edge_weight_t>::type weightmap = get(edge_weight, g); graph_traits<graph>::edge_descriptor e; bool inserted; tie(e,inserted) = add_edge(0,1,g); weightmap[e]=1; cout << inserted << endl; tie(e,inserted) = add_edge(0,2,g); weightmap[e]=1; cout << inserted << endl; tie(e,inserted) = add_edge(1,2,g); weightmap[e]=1; cout << inserted << endl; tie(e,inserted) = add_edge(2,2,g); weightmap[e]=0.1; cout << inserted << endl; std::vector < graph_traits < graph >::vertex_descriptor > p(num_vertices(g)); prim_minimum_spanning_tree(g, &p[0]); for (size_t i=0; i != p.size(); i++) { std::cout << "mst parent[" << i << "] = " << p[i] << std::endl; } return 0; } Output: 1 1 1 1 mst parent[0] = 0 mst parent[1] = 0 mst parent[2] = 2 Desired output: mst parent[2] = 0 ( or mst parent[2] = 1 )

1 0

[thread] boost-1.36's upgrade_to_unique_lock doesn't compile on C++0x mode
by Rodolfo Lima 08 Oct '08

08 Oct '08

The following code doesn't compile with gcc-4.3.2 (and gcc-4.4.0), and boost-1.36 (and boost-trunk of 2008/10/07) when using -std=c++0x on linux. #include <boost/thread/shared_mutex.hpp> int main() { boost::shared_mutex mtx; boost::upgrade_lock<boost::shared_mutex> lk(mtx); boost::upgrade_to_unique_lock<boost::shared_mutex> lk2(lk); } gcc spits: g++-4.4.0-alpha20081003 -std=c++0x -I src/boost-trunk teste.cpp -o teste In file included from src/boost-trunk/boost/thread/pthread/mutex.hpp:11, from src/boost-trunk/boost/thread/mutex.hpp:16, from src/boost-trunk/boost/thread/pthread/shared_mutex.hpp:12, from src/boost-trunk/boost/thread/shared_mutex.hpp:16, from teste.cpp:1: src/boost-trunk/boost/thread/locks.hpp: In destructor 'boost::upgrade_to_unique_lock<Mutex>::~upgrade_to_unique_lock() [with Mutex = boost::shared_mutex]': teste.cpp:8: instantiated from here src/boost-trunk/boost/thread/locks.hpp:807: error: no match for 'operator=' in '*((boost::upgrade_to_unique_lock<boost::shared_mutex>*)this)->boost::upgrade_to_unique_lock<boost::shared_mutex>::source = boost::move [with Mutex = boost::shared_mutex](((boost::unique_lock<boost::shared_mutex>&&)(&((boost::upgrade_to_unique_lock<boost::shared_mutex>*)this)->boost::upgrade_to_unique_lock<boost::shared_mutex>::exclusive)))' src/boost-trunk/boost/thread/locks.hpp:643: note: candidates are: boost::upgrade_lock<Mutex>& boost::upgrade_lock<Mutex>::operator=(boost::upgrade_lock<Mutex>&) [with Mutex = boost::shared_mutex] src/boost-trunk/boost/thread/locks.hpp:694: note: boost::upgrade_lock<Mutex>& boost::upgrade_lock<Mutex>::operator=(boost::detail::thread_move_t<boost::upgrade_lock<Mutex> >) [with Mutex = boost::shared_mutex] src/boost-trunk/boost/thread/locks.hpp:701: note: boost::upgrade_lock<Mutex>& boost::upgrade_lock<Mutex>::operator=(boost::detail::thread_move_t<boost::unique_lock<Mutex> >) [with Mutex = boost::shared_mutex] src/boost-trunk/boost/thread/locks.hpp: In constructor 'boost::unique_lock<Mutex>::unique_lock(boost::upgrade_lock<Mutex>&&) [with Mutex = boost::shared_mutex]': src/boost-trunk/boost/thread/locks.hpp:801: instantiated from 'boost::upgrade_to_unique_lock<Mutex>::upgrade_to_unique_lock(boost::upgrade_lock<Mutex>&) [with Mutex = boost::shared_mutex]' teste.cpp:8: instantiated from here src/boost-trunk/boost/thread/locks.hpp:775: error: request for member 'unlock_upgrade_and_lock' in '((boost::unique_lock<boost::shared_mutex>*)this)->boost::unique_lock<boost::shared_mutex>::m', which is of non-class type 'boost::shared_mutex*' It compiles fine in non std++0x mode Regards, Rodolfo Lima

1 0

boost::python -- passing containers of shared pointers as arguments and getting automatic conversion
by Eric Jonas 08 Oct '08

08 Oct '08

Hello! I've found several examples of code on the internet where people are trying to convert from a native python container type to a std::container. Using those as a template, I'm trying to convert from a python tuple of objects wrapped by boost::python to a std::vector of boost::shared_ptrs. Example c++: http://pastebin.com/m3b198a9c Example python showing the code running: http://pastebin.com/m400f17e1 Example output: http://pastebin.com/m1b0eb94e [all pasted at the end of the mail] [Please note these only work if you've hacked your boost/shared_ptr.hpp to make everything public] Unfortunately, I'm running into a problem with extract<shared_ptr<T>> creating a -new- shared pointer pointing to the raw pointer -within- the existing shared pointer -- so no reference-comanaging occurs. I've hacked my shared_ptr.hpp to let me examine the refcounted struct inside the shared pointer. What I see when I run things is as follows: [jonas@hamiltonian core]$ python broken_test.py Foo 0 is at 88276256 with reference counter 8276288 Foo 1 is at 88276352 with reference counter 8276384 Foo 2 is at 88276320 with reference counter 8276416 Extraction of object pointing to 88276256 but with reference counter 0x7f54c0 Extraction of object pointing to 88276352 but with reference counter 0x7f3f80 Extraction of object pointing to 88276320 but with reference counter 0x7e4a00 Note what this is saying: While internal to my FooHolder, the shared pointers point to location X and reference-counting struct Y, within the converter they're being turned into new shared pointers, still managing the raw pointer X but with a different reference-counting-struct Z. This is most perplexing, and I worry it might be the result of interaction with the fact that in my example code, I'm explicitly using the shared pointer to manage the reference count: class_<Foo, pFoo_t>("Foo"); In any case, I'm quite stumped, and have a -ton- of places in my main codebase where stl containers are passed around containing shared_ptrs. I asked around on IRC but everyone seemed stumped too. Any help would be greatly appreciated. Thanks! ...Eric Jonas broken.cc: #include <boost/python.hpp> #include <boost/python/class.hpp> #include <boost/python/converter/shared_ptr_from_python.hpp> #include <boost/python/implicit.hpp> #include <boost/python/module.hpp> #include <boost/variant/apply_visitor.hpp> #include <boost/shared_ptr.hpp> #include <vector> using namespace boost::python; using namespace std; template <class T1> struct vector_from_tuple_of_shared { vector_from_tuple_of_shared() { converter::registry::push_back(&convertible, &construct, boost::python::type_id<std::vector<T1> >()); } static void* convertible(PyObject* obj_ptr) { handle<> x(borrowed(obj_ptr)); boost::python::tuple o(x); for (int i = 0; i < boost::python::len(o); i++) { extract<T1> obj(o[i]); if (!obj.check() ) { return 0; } } return obj_ptr; } static void construct(PyObject* obj_ptr, converter::rvalue_from_python_stage1_data* data) { handle<> x(borrowed(obj_ptr)); std::vector<T1> value; boost::python::tuple o(x); for (int i = 0; i < boost::python::len(o); i++) { extract<T1> obj(o[i]); T1 s1 = obj; std::cout << "Extraction of object pointing to " << ios::hex << (int64_t) s1.get() << " but with reference counter " << s1.pn.pi_ << std::endl; value.push_back(obj); } void* storage = ( (converter::rvalue_from_python_storage<std::vector<T1> >*) data)->storage.bytes; new (storage) std::vector<T1>(value); data->convertible = storage; } }; class Foo { }; typedef boost::shared_ptr<Foo> pFoo_t; class FooHolder { public: std::vector<pFoo_t> foos_; pFoo_t createFoo() { pFoo_t f(new Foo()); foos_.push_back(f); return f; } void printFooStatus() { for(int i = 0; i < foos_.size(); i++) { std::cout << "Foo " << i << " is at " << ios::hex << (int64_t)foos_[i].get() << " with reference counter " << (int64_t)foos_[i].pn.pi_ << std::endl; } } }; void doStuff(std::vector<pFoo_t> stuff) { } BOOST_PYTHON_MODULE(broken) { class_<Foo, pFoo_t>("Foo"); class_<FooHolder>("FooHolder") .def("createFoo", &FooHolder::createFoo) .def("printFooStatus", &FooHolder::printFooStatus) ; def("doStuff", &doStuff); vector_from_tuple_of_shared<pFoo_t>(); } Broken.py: import broken fh = broken.FooHolder() f1 = fh.createFoo() f2 = fh.createFoo() f3 = fh.createFoo() fh.printFooStatus() broken.doStuff((f1, f2, f3)) Output: [again, requires modified shared_ptr.hpp] jonas@hamiltonian core]$ make broken.so g++ -O2 -g -pg -I/usr/local/include -fPIC -I../threadpool/threadpool/include -pthread -fPIC -I/usr/include/`/usr/bin/python -c "import sys; (a, b, c, t, n) = sys.version_info; print 'python%d.%d' % (a, b),"` -c broken.cc g++ broken.o -L/usr/local/lib -lgsl -lgslcblas -lm -lboost_unit_test_framework -lboost_program_options -g -pg -lboost_thread -lboost_signals -o broken.so -shared -I/usr/include/`/usr/bin/python -c "import sys; (a, b, c, t, n) = sys.version_info; print 'python%d.%d' % (a, b),"` \ -L/usr/lib -lpython2.4 -lboost_python [jonas@hamiltonian core]$ python broken_test.py Foo 0 is at 88276256 with reference counter 8276288 Foo 1 is at 88276352 with reference counter 8276384 Foo 2 is at 88276320 with reference counter 8276416 Extraction of object pointing to 88276256 but with reference counter 0x7f54c0 Extraction of object pointing to 88276352 but with reference counter 0x7f3f80 Extraction of object pointing to 88276320 but with reference counter 0x7e4a00

1 0

[Graph] Issue with is_straight_line_drawing?
by David Gleich 08 Oct '08

08 Oct '08

Hi, I'm concerned about the output I'm getting from the is_straight_line_drawing function in the Boost Graph library. My understanding was that it should report true when the graph and positions are a planar embedding (no edge crossings). Based on this understanding, I thought the code listed at the end of the message should say that the drawing for a clique on 4 vertices, with positions on a square, is not planar (see the picture below). This arrangement has one edge crossing. The function outputs that the graph is a plane drawing. Did I misunderstand what the is_straight_line_drawing function is supposed to do? Thanks, David Gleich #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> #include <vector> #include <boost/graph/is_straight_line_drawing.hpp> using namespace boost; //a class to hold the coordinates of the straight line embedding struct coord_t { std::size_t x; std::size_t y; }; int main(int argc, char** argv) { typedef adjacency_list < vecS, vecS, undirectedS, property<vertex_index_t, int> > graph; graph g(4); // make the clique on 4 vertices add_edge(0,1,g); add_edge(0,2,g); add_edge(0,3,g); add_edge(1,2,g); add_edge(1,3,g); add_edge(2,3,g); //Set up a property map to hold the mapping from vertices to coord_t's typedef std::vector< coord_t > straight_line_drawing_storage_t; typedef boost::iterator_property_map < straight_line_drawing_storage_t::iterator, property_map<graph, vertex_index_t>::type > straight_line_drawing_t; straight_line_drawing_storage_t straight_line_drawing_storage (num_vertices(g)); straight_line_drawing_t straight_line_drawing (straight_line_drawing_storage.begin(), get(vertex_index,g) ); /* should be 0 / | \ 3--|--1 \ | / 2 which is not a plane drawing. */ straight_line_drawing[0].x = 1; straight_line_drawing[0].y = 2; straight_line_drawing[1].x = 2; straight_line_drawing[1].y = 1; straight_line_drawing[2].x = 1; straight_line_drawing[2].y = 0; straight_line_drawing[3].x = 0; straight_line_drawing[3].y = 1; if (is_straight_line_drawing(g, straight_line_drawing)) std::cout << "Is a plane drawing." << std::endl; else std::cout << "Is not a plane drawing." << std::endl; return 0; } /* Compiling and example $ g++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) $g++ is_straight_line_drawing.cpp -I/home/dgleich/dev/lib/boost_1_36_0/ $./a.out Is a plane drawing. Should be Is not a plane drawing. */

2 5

boost::mpl::map and boost::mpl::for_each -- code does not compile -- any help appreciated
by peter_foelsche＠agilent.com 07 Oct '08

07 Oct '08

#include <boost/mpl/map.hpp> #include <iostream> #include <boost/mpl/at.hpp> #include <boost/mpl/placeholders.hpp> #include <boost/mpl/for_each.hpp> typedef boost::mpl::map< boost::mpl::pair< boost::mpl::int_<0>, boost::mpl::int_<3> >, boost::mpl::pair< boost::mpl::int_<1>, boost::mpl::int_<2> >, boost::mpl::pair< boost::mpl::int_<2>, boost::mpl::int_<1> >, boost::mpl::pair< boost::mpl::int_<3>, boost::mpl::int_<0> > > CMapForward; typedef boost::mpl::map< boost::mpl::pair< boost::mpl::int_<0>, boost::mpl::int_<3> >, boost::mpl::pair< boost::mpl::int_<1>, boost::mpl::int_<2> >, boost::mpl::pair< boost::mpl::int_<2>, boost::mpl::int_<1> >, boost::mpl::pair< boost::mpl::int_<3>, boost::mpl::int_<0> > > CMapReverse; template<typename I2E_PAIR, typename E2I> struct CCreatePair:boost::mpl::pair<typename I2E_PAIR::first, boost::mpl::at<E2I, typename I2E_PAIR::second> > { }; struct CDoSomething { template<unsigned int INDEX0, unsigned int INDEX1> inline void operator()(const boost::mpl::pair<boost::mpl::int_<INDEX0>, boost::mpl::int_<INDEX1> > &_r) const { std::cout << INDEX0 << " " << INDEX1 << "\n"; } }; int main(int, char**) { boost::mpl::for_each< CMapForward, template CCreatePair<boost::mpl::_1, CMapReverse> >(CDoSomething()); return 0; } "The first point (using an init() function in preference to a constructor) is bogus. Using constructors and exception handling is a more general and systematic way of dealing with resource acquisition and initialization errors. This style is a relic of pre-exception C++." -- Stroustrup

2 1

[Graph] Subgraphs with bundled properties
by Cooprider, Nathan (US NonSSA) 07 Oct '08

07 Oct '08

I am having some difficulty getting bundled properties working with subgraphs in the BGL. Some sample code is below. If I comment out the subgraph line and rename "PlainGraph" to be just "Graph" then the code compiles. As it is written below, I get a type error (copied below the code below). Any help/pointers would be appreciated. Thank you. Nathan #include <string> #include <boost/graph/adjacency_list.hpp> #include <boost/config.hpp> #include <boost/graph/subgraph.hpp> using namespace boost; struct Node { std::string name; float weight; }; typedef adjacency_list < setS, setS, directedS, property<vertex_index_t, int, Node >, property<edge_index_t, int> > PlainGraph; typedef subgraph<PlainGraph> Graph; int main () { Graph g; Graph::vertex_descriptor tmp = add_vertex(g); put(vertex_index, g, tmp, 42); } Here is the error: /home/ncooprid/local/include/boost/graph/subgraph.hpp: In member function 'typename boost::property_traits<IndexMap>::reference boost::subgraph_local_property_map<GraphPtr, PropertyMap, Tag>::operator[](typename boost::property_traits<IndexMap>::key_type) const [with GraphPtr = boost::subgraph<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, int, Node>, boost::property<boost::edge_index_t, int, boost::no_property>, boost::no_property, boost::listS> >*, PropertyMap = boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, int, Node>, boost::property<boost::edge_index_t, int, boost::no_property>, boost::no_property, boost::listS>, int, int&, boost::vert ex_index_t>, Tag = boost::vertex_index_t]': /home/ncooprid/local/include/boost/graph/subgraph.hpp:843: instantiated from 'void boost::put(Property, boost::subgraph<Graph>&, const Key&, const Value&) [with G = boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, int, Node>, boost::property<boost::edge_index_t, int, boost::no_property>, boost::no_property, boost::listS>, Property = boost::vertex_index_t, Key = void*, Value = int]' error.cpp:24: instantiated from here /home/ncooprid/local/include/boost/graph/subgraph.hpp:738: error: conversion from 'boost::subgraph_local_property_map<boost::subgraph<boost::adjacency_lis t<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, int, Node>, boost::property<boost::edge_index_t, int, boost::no_property>, boost: :no_property, boost::listS> >*, boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, int, Node>, boost::property<boost::edge_index_t, int, boost::no_property>, boost::no_property, boost::listS>, int, int&, boost::vertex_index_t>, boost::vertex_index_t>' to non-scalar type 'boost::adj_list_vertex_property_map<boost::adjacency_list<boost::setS, boost::setS, boost::directedS, boost::property<boost::vertex_index_t, int, Node>, boost::property<boost::edge_index_t, int, boost::no_property>, boost::no_property, boost::listS>, int, int&, boost::vertex_index_t>' requested

1 0

Re: [Boost-users] Error:" Non-const function called for const object" on Sun CC while using boost::multi_index::multi_index_container
by JOAQUIN M. LOPEZ MUÑOZ 07 Oct '08

07 Oct '08

De: Alexander Vinokur [Alexander.Vinokur(a)amdocs.com] Enviado el: martes, 07 de octubre de 2008 18:28 Para: boost-users(a)lists.boost.org CC: JOAQUIN M. LOPEZ MUÑOZ Asunto: RE: Error:" Non-const function called for const object" on Sun CC while using boost::multi_index::multi_index_container > > Joaquin, thank you. > > Here code I compiled. > > // --- File foo3.cpp --- > [...] > const Bar* p4 = new Bar; > p4->~Bar(); // line 19: Error: Non-const function > Bar::__SLIP.DELETER__A() called for const object. OK, seems like the bug we were after, if only in a slightly different guise (deleting a const T* works, but directly calling ~T() on a const object does not). Alex, can you do the following? Please try replacing the /boost/detail/allocator_utilities.hpp file in your local Boost copy with the attached file and rebuild the multi_index_container code that was failing. Does this fix it? If so, I'll commit this version into the trunk so that it'll be available in Boost 1.38 (though you can use it now with your local Boost copy, of course). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

It is possible to build a static version of boost for the MACOS
by kittymaguire 07 Oct '08

07 Oct '08

Hi I have tried to build the boost libraries on the MacOS as a static library by giving bjam the --buid_type=static but it still built the dynamic version of the libraries. In order to get my application to run, the library load location has to be either in /usr/lib or from the folder where the application started. The problem is that our application is based on xulrunner, and we use a stub application to start xulrunner which is in a different folder. We use the boost libraries in an XPCOM dylib which is loaded from the resources components folder, and for this dylib to be loaded correctly the boost libraries need to placed in the stub application folder. The first time you start the application it will run on but will then fail to run the second time you start it as libraries are being loaded from a location that xulrunner allows it components to run from. So either I need to build the static version of the libraries or change the runtime load path of the libraries. Does anyone know how I do any of these Thanks -- View this message in context: http://www.nabble.com/It-is-possible-to-build-a-static-version-of-boost-for… Sent from the Boost - Users mailing list archive at Nabble.com.

8 17