- Boost-users - lists.boost.org

[Boost.Bimap] templated Bimaps and tagging; efficiency
by Christoph Duelli 08 Oct '08

08 Oct '08

I'd like to replace a bidirectional mapping (2 std::maps so far) with Boost.Bimap. Being based on Boost.MultiIndex I hope there are some space savings there (also I could not find specifics in the docs). I have run into some questions/issues that I hope someone can shed light upon. i) I insert a name/value pair like: typedef boost::bimap<std::string, int> MyBimap; MyBimap myBimap; bool ok = myBimap.insert( typename MyBimap::value_type(name,val) ).second; Is it possible (w/o checking afterwards) to find out *why* the insert failed? (It might be a duplicate on the left or the right side. I want to print a helpful debug message...) ii) I would like to use a Bimap in a templated class: Works ok. When I try to tag the bimap, I get the following errors (using gcc 4.1.2) error: expected primary-expression before 'template' error: expected `;' before 'template' (The errors are the calls to by<country>() // wrapped tagged_simple_bimap.cpp from the Bimap docs in a template class: template<typename T> class X { typedef bimap < tagged< std::string, country >, tagged< T , place > > results_bimap; ... }; (I have attached the modified example.) Tagging works if the bimap definition does contain templated types. Any ideas what I am doing wrong? iii) I need the order of my insertions at one place in my code. Do I lose lookup efficiency (on the left side) when I declare my map as: typedef bimap <vector_of<std::string>, int> (My (bi)map is initialized once and then used for lookups only. Is it better in that case to store the insertion order in a separate vector? Or should I go for the more awe-inspiring Boost.Multimap if I want a Bimap (with efficient lookup) *and* have access to the insertion order? ) iv) What is the difference between: typedef bimap< std::string, int, list_of_relation> ...; and typedef bimap< vector_of<std::string>, int> ...; Thank you for a helpful library (collection). Christoph

1 0

[filesystem] Problem mixing read and write on io fstream
by Sachin Garg 08 Oct '08

08 Oct '08

I have a program which opens a boost fstream in binary input+output mode, creating the file if it doesn't exists. But writing doesn't works after reading, it must be something obvious that I am not aware of. filename is a wpath. f.open(filename,ios::in | ios::out | ios::binary | ios::trunc) The program flow is 1) write some data 2) read the data 3) overwrite old data //this fails I am aware that mixing reading and writting is complicated due to buffering and as far as I know the solution is to do a seekg or seekp when changing between reading and writting, I am doing this between 1, 2 and 3. In 'my' program, writting in step 3 fails. I wrote a simple program that does just the above 3 steps with seeks and it works but in my program, it sets the failbit. After lots of debugging in internal fstream code I figured that an internal flag _IOREAD gets set somehow in step 2 which indicates that the stream is now readonly and causes subsequent writes to fail. It also seems that _IOREAD is set anytime any read operation is done on a read+write file, is this correct? And now how do I 'unset' this flag? I tried calling f.clear and f.seekp but that doesnt helps. What might be special in my program that causes this read-mode flag to remain set while this doesn't happens in a barebone/simple test program. I am not doing anything except f.seekg, f.get, f.read. Sachin Garg ps. If it matters, I am using visual studio 9.0. Problem might not be boost specific as boost only uses stl fstream but any help will be really useful.

3 2

Re: [Boost-users] [program_options] linker error LNK2005 (symbol already defined in object)
by Andrei LIHU 08 Oct '08

08 Oct '08

I think I had this problem too a long time ago. I fixed that in \include\boost\boost\program_options\variables_map.hpp. Here is the standard Unix diff for that file. 128c128 < friend void store(const basic_parsed_options<char>& options, --- > friend void BOOST_PROGRAM_OPTIONS_DECL store(const basic_parsed_options<char>& options, -- Check if it works this way for you. Kind regards, Andrei LIHU -------------------- C++ Software Developer +40742545392

1 0

Boost Program Options Optional Value (request for implicit_value() behaviour change to allow space)
by Andrei LIHU 08 Oct '08

08 Oct '08

Description of the real problem: - let "-b" be the name of the option - it disables, if not present in command line, the general app logging - it enables, if present in command line, the general app logging in a default chosen logfile - it enables, if present in command line with a string argument, the general app logging into the file specified as string argument Usage example: >> program_name (no logging) >> program_name -b (logging enabled; goes to logfile.log) >> program_name -b "C:\otherlogfile.log" (logs where specified) So far I found a solution based on implicit_value() behaviour, with "-b" of type string, but my main problem is that in this case I am forced to enter the value to be adjacent to "-b" (e.g. -b"C:\otherlogfile.log"). The desired form would be the one with a space between, in order to maintain our backward compatibility of scripts (e.g: -b "C:\otherlogfile.log"). Can you help me with a good solution? (Even solutions that crack into the source of boost program options library are appreciated.) Thank you for your time. -- Kind regards, Andrei LIHU -------------------- softNRG C++ Software Developer +40742545392

2 2

[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