September 2005 - Boost-users - lists.preview.boost.org

Serialization of template classes via base
by Bruno Martínez 12 Sep '05

12 Sep '05

Hi. This has been asked before here http://lists.boost.org/boost-users/2005/05/11706.php but I didn't understand the workaround. What I want is to serialize class B where class A { ... }; template<...> class B : public A { ... }; when I have an A*. The workarounds proposed were using RTTI non portably, or registering the classes each time. How would such solution look like? Regards, Bruno

3 8

Boost post on codetools
by gast128 11 Sep '05

11 Sep '05

I have posted two articles ('File rename using boost regex and boost file system' and 'Building boost libraries for Visual Studio')on www.codetools.com on Boost issues. In this way I hope to promote Boost use in a community which is more geared towards MFC use. Wkr, me

1 0

boost-1.33, [date_time]: missing std::localtime_r/gmtime_r
by Michael Haubenwallner 11 Sep '05

11 Sep '05

Hi, There's a problem on HP-UX (especially hppa2.0w-hp-hpux11.11) with gcc-3.3.6, where localtime_r and gmtime_r are not in namespace std. boost-1.33 itself is built with "<cxxflags>-pthread/<linkflags>-pthread" $ cat xx.cc #include <boost/date_time/posix_time/posix_time_system.hpp> $ g++ -pthread xx.cc In file included from /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/date_clock_device.hpp:12, from /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/gregorian/gregorian_types.hpp:26, from /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/posix_time/posix_time_config.hpp:14, from /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/posix_time/posix_time_system.hpp:13, from xx.cc:1: /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/c_time.hpp: In static member function `static tm* boost::date_time::c_time::localtime(const time_t*, tm*)': /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/c_time.hpp:56: error: ` localtime_r' undeclared in namespace `std' /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/c_time.hpp: In static member function `static tm* boost::date_time::c_time::gmtime(const time_t*, tm*)': /tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/boost/include/boost/date_time/c_time.hpp:64: error: ` gmtime_r' undeclared in namespace `std' $ $ gcc -v Reading specs from /mnt/toolsjunk/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.3.6/specs Configured with: /mnt/toolsjunk/snapshot/src/sasrvb/toolsbox-3.5.0.16rc.20050904/buildroot/gcc/gcc-3.3.6/configure --with-gnu-as --with-as=/tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX/hppa2.0w-hp-hpux11.11/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --with-local-prefix=/tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX --disable-nls --prefix=/tools/snapshot/toolsbox-3.5.0.16rc.20050904/HP-UX Thread model: posix gcc version 3.3.6 Two maybe interesting notes: 1) /usr/include/time.h only declares localtime_r/gmtime_r if '-pthread' compiler-flag is used (and therefore _REENTRANT is defined). 2) gcc-shipped <ctime> does not pull localtime_r/gmtime_r into namespace std Thanks! ~haubi -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz mailto:michael.haubenwallner@salomon.at http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html

3 3

Re: [Boost-users] [preprocessor] break "names"
by Mihalicza, Jozsef 10 Sep '05

10 Sep '05

Hi, Not a naive question, check this: http://lists.boost.org/Archives/boost/2005/03/83253.php Regards, József Mihalicza ________________________________ Feladó: boost-users-bounces(a)lists.boost.org meghatalmazó: Felipe Magno de Almeida Hi, Maybe it is a naive question, but I've been researching a little and couldnt find an answer to this(not an affirmative and nor negative): Is it possible to have such usages: SOME_MACRO(hello world) or SOME_MACRO("hello world") (or something that doesnt have much "characters overhead", like using space for every character) and have the expansion result in this: h e l l o w o r l d or even better: 'h','e','l','l','o', ' ', 'w', 'o', 'r', 'l', 'd' Well, what I'm trying to find is if it is possible to give something to a macro and the macro create an vector_c with all the characters inside it. Like: SOME_MACRO(Hello World) and expand to: boost::mpl::vector<char, 'H','e','l','l','o',' ','W','o','r','l','d'> Thanks in advance, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark." _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

Serialization segfaulting
by Dmitriy Morozov 10 Sep '05

10 Sep '05

Hi, I'm having problems with boost serialization library. There are two cases in which it is segfaulting on me. One is during a register_type() call, but we can discuss that one later. Another one which I am trying to debug right now is when I am trying to serialize a large binary tree (lots of pointers all over the place, sometimes pointing at themselves, sometimes at 0, sometimes jumping all over the tree). I am not quite sure how to approach the debugging of this issue since for some reason I am not able to step into the boost serialization routines themselves (but I'm not so good with the debugger). The actual segfault as given by DDD is: Program received signal SIGSEGV, Segmentation fault. 0x40075b75 in std::_Rb_tree<boost::archive::detail::basic_oarchive_impl::cobject_type, boost::archive::detail::basic_oarchive_impl::cobject_type, std::_Identity<boost::archive::detail::basic_oarchive_impl::cobject_type>, std::less<boost::archive::detail::basic_oarchive_impl::cobject_type>, std::allocator<boost::archive::detail::basic_oarchive_impl::cobject_type> >::insert_unique(boost::archive::detail::basic_oarchive_impl::cobject_type const&) () from /usr/lib/libboost_serialization.so.1.33.0 Any advice is appreciated. Best, Dmitriy P.S. On a completely unrelated note, when the abstract base class is a template, the BOOST_IS_ABSTRACT macro is not applicable. It would be helpful if the documentation listed the chunk of code that needs to be added in that case. It's pretty easy to find it in the header files (is_abstract.hpp), but it may be helpful to just list it.

2 3

[preprocessor] break "names"
by Felipe Magno de Almeida 10 Sep '05

10 Sep '05

Hi, Maybe it is a naive question, but I've been researching a little and couldnt find an answer to this(not an affirmative and nor negative): Is it possible to have such usages: SOME_MACRO(hello world) or SOME_MACRO("hello world") (or something that doesnt have much "characters overhead", like using space for every character) and have the expansion result in this: h e l l o w o r l d or even better: 'h','e','l','l','o', ' ', 'w', 'o', 'r', 'l', 'd' Well, what I'm trying to find is if it is possible to give something to a macro and the macro create an vector_c with all the characters inside it. Like: SOME_MACRO(Hello World) and expand to: boost::mpl::vector<char, 'H','e','l','l','o',' ','W','o','r','l','d'> Thanks in advance, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."

1 0

boost-1.33 [date_time] simple_format template: missing default for <charT>
by Michael Haubenwallner 10 Sep '05

10 Sep '05

Hi, is there any reason besides being a bug why the formatters found in boost/date_time/date_formatting.hpp have a default value 'char' for template argument 'charT', but boost::date_time::simple_format does not ? Thanks, haubi -- Michael Haubenwallner SALOMON Automation GmbH Forschung & Entwicklung A-8114 Friesach bei Graz mailto:michael.haubenwallner@salomon.at http://www.salomon.at No HTML/MIME please, see http://expita.com/nomime.html

1 0

Re: [Boost-users] Thread events
by Christopher Hunt 10 Sep '05

10 Sep '05

On 10/09/2005, at 2:12 AM, boost-users-request(a)lists.boost.org wrote: >> Thanks for your replies. >> >> To me boost::condition looks very much like the old event >> variable, except >> that it works together with a mutex. I am now wondering why you >> should >> lock >> a mutex before waiting for the condition? Is there a rationale >> about this? > Also note that the wait() on the condition unlocks the mutex until you > return from the wait call. That's not always obvious from the > examples. Someone else mentioned the Butenhof book so I won't go down that path; suffice to state that anyone that wants to do any thread programming absolutely must read that book. In fact, the book really is more about thread paradigms than pthreads. IMHO pthreads are more of a case study in the book. A quick example to fill in the time between you ordering the book and receiving it might help. Suppose you have a mutex for the purpose of protecting a variable. Suppose you must also wait on a condition because that variable isn't in a state that you need to progress. If you keep the mutex locked while waiting on a condition then no other thread will get the opportunity to modify the variable's value. To solve this many programmers will just unlock the mutex prior to waiting on the condition. However, the problem with this approach is that in the time between the mutex being unlocked, and the condition is waited on, another thread can come along, lock the mutex and change the variable. Thus you might be waiting on a condition that never occurs. Remember that conditions are generally signaled only to threads currently waiting on them or to the 1st thread that comes along and waits on a condition. Thus, if you're not waiting on a condition, you may never receive its signal. You may think that the chances of another thread coming along and upsetting your world are slim, but one day, it will happen and you'll be wanting to ignore that bug in your app 'cause it'll be hard to reproduce. pthread conditions are associated with mutexes so that they guarantee to unlock a mutex and wait on a condition without the chance of another thread coming along and doing what is described above. From an implementation perspective, I imagine pthread conditions enter into a critical section while they unlock a mutex and move to a wait state. As stated before, when you return from the condition, the mutex will be locked again, and you should re-test for your condition. Something like the following logic may help: ***** lock mutex while var not in state you need to proceed { wait on condition associated with mutex } unlock mutex do your stuff. ***** Note that it is also healthy to unlock your mutexes asap so as to reduce contention. 'hope that this helps. Cheers, -C

1 0

Problem with BGL copy_graph algorithm - HELP
by Tony Cook 09 Sep '05

09 Sep '05

Hello, Can anyone tell me if I've exposed a bug in the Boost Graph Library or if the following behaviour is expected and I need to code the solution in a different way, and if so HOW? In summary the boost::copy_graph algorithm fails to compile when defining the graph using std::vector for the edge container and std::list for the vertex container (Visual Studio 7.1, Boost 1.32.0). Other graph type definitions work. (NB I can't use the "working" graph types in my main application as VC 7.1 bombs with an Internal Compiler Error. I'm forced to use a vecS,lists graph just to work round the ICE problem!!). I've distilled the problem down to the minimum code possible. ------------------------------------------------- // A vecS, vecS based graph works typedef boost::adjacency_list <boost::vecS, boost::vecS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> GoodGraphType ; GoodGraphType good_graph_1 ; GoodGraphType good_graph_2 ; boost::copy_graph (good_graph_1, good_graph_2) ; // Compiles OK ------------------------------------------------- // A listS, vecS based graph also works typedef boost::adjacency_list <boost::listS, boost::vecS, boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> AnotherGoodGraphType ; AnotherGoodGraphType another_good_graph_1 ; AnotherGoodGraphType another_good_graph_2 ; boost::copy_graph (another_good_graph_1, another_good_graph_2) ; // Compiles OK ------------------------------------------------- // A vecS, lists based graph fails to compile - BGL error or expected?? typedef boost::adjacency_list <boost::vecS, boost::listS, // root cause of compilation failure boost::undirectedS, boost::no_property, boost::no_property, boost::no_property> BadGraphType ; BadGraphType bad_graph_1 ; BadGraphType bad_graph_2 ; boost::copy_graph (bad_graph_1, bad_graph_2) ; // ***** Does not compile ****** ------------------------------------------------------- Here is the exact wording of the VC7.1 compiler output. ------------------------------------------------------- ..\boost_1_32_0\boost\property_map.hpp(349) : error C2678: binary '+' : no operator found which takes a left-hand operand of type 'const std::vector<_Ty>::iterator' (or there is no acceptable conversion) with [ _Ty=boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS,boost::vec S,boost::undirectedS,boost::no_property,boost::no_property,boost::no_propert y>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::retag_property_ list<boost::vertex_bundle_t,boost::no_property>::type,boost::detail::retag_p roperty_list<boost::edge_bundle_t,boost::no_property>::type,boost::no_proper ty,boost::listS>::config::vertex_ptr ] ...\boost_1_32_0\boost\property_map.hpp(349) : while compiling class-template member function 'void boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>::operator [](boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>::key_type ) const' with [ RandomAccessIterator=std::vector<boost::detail::adj_list_gen<boost::adjacenc y_list<boost::vecS,boost::vecS,boost::undirectedS,boost::no_property,boost:: no_property,boost::no_property>,boost::vecS,boost::vecS,boost::undirectedS,b oost::detail::retag_property_list<boost::vertex_bundle_t,boost::no_property> ::type,boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_pro perty>::type,boost::no_property,boost::listS>::config::vertex_ptr >::iterator, IndexMap=boost::property_map<boost::adjacency_list<boost::vecS,boost::listS, boost::undirectedS,boost::no_property,boost::no_property,boost::no_property> ,boost::vertex_index_t>::const_type, T=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type, R=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type & ] ...\boost_1_32_0\boost\graph\copy.hpp(323) : see reference to class template instantiation 'boost::iterator_property_map<RandomAccessIterator,IndexMap,T,R>' being compiled with [ RandomAccessIterator=std::vector<boost::detail::adj_list_gen<boost::adjacenc y_list<boost::vecS,boost::vecS,boost::undirectedS,boost::no_property,boost:: no_property,boost::no_property>,boost::vecS,boost::vecS,boost::undirectedS,b oost::detail::retag_property_list<boost::vertex_bundle_t,boost::no_property> ::type,boost::detail::retag_property_list<boost::edge_bundle_t,boost::no_pro perty>::type,boost::no_property,boost::listS>::config::vertex_ptr >::iterator, IndexMap=boost::property_map<boost::adjacency_list<boost::vecS,boost::listS, boost::undirectedS,boost::no_property,boost::no_property,boost::no_property> ,boost::vertex_index_t>::const_type, T=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type, R=std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::ve cS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property,boos t::no_property>,boost::vecS,boost::vecS,boost::undirectedS,boost::detail::re tag_property_list<boost::vertex_bundle_t,boost::no_property>::type,boost::de tail::retag_property_list<boost::edge_bundle_t,boost::no_property>::type,boo st::no_property,boost::listS>::config::vertex_ptr >::value_type & ] ...\CopyGraphTest.cpp(50) : see reference to function template instantiation 'void boost::copy_graph<BadGraphType,BadGraphType>(const VertexListGraph &,MutableGraph &)' being compiled with [ VertexListGraph=BadGraphType, MutableGraph=BadGraphType ] ------------------------------------------------------- Here is the code from property_map.hpp the generates the error - error line marked with //<----- HERE //========================================================================= // Adapter to turn a RandomAccessIterator into a property map template <class RandomAccessIterator, class IndexMap #ifdef BOOST_NO_STD_ITERATOR_TRAITS , class T, class R #else , class T = typename std::iterator_traits<RandomAccessIterator>::value_type , class R = typename std::iterator_traits<RandomAccessIterator>::reference #endif > class iterator_property_map : public boost::put_get_helper< R, iterator_property_map<RandomAccessIterator, IndexMap, T, R> > { public: typedef typename property_traits<IndexMap>::key_type key_type; typedef T value_type; typedef R reference; typedef boost::lvalue_property_map_tag category; inline iterator_property_map( RandomAccessIterator cc = RandomAccessIterator(), const IndexMap& _id = IndexMap() ) : iter(cc), index(_id) { } inline R operator[](key_type v) const { return *(iter + get(index, v)) ; } //<----- HERE protected: RandomAccessIterator iter; IndexMap index; }; -------------------------------------------------------- TIA for any help in this matter Tony Cook

2 1

[BGL] Help with Brandes' Betweenness
by Rui Carvalho 09 Sep '05

09 Sep '05

Hi, I'm trying to write code to compute Brandes' Betweenness Centrality for a very simple graph: a star. I'm doing this, as I haven't been able to find simple examples in the documentation [hint :)] for vecS,vecS graphs and still haven't grasped how edge property maps work. I've got it running if all I want is to compute vertex BC (see below, also attached), but can't get it to compute both vertex and edge BC. I'd appreciate any suggestions -perhaps my example (or something similar) could be corrected and included in the BGL? Thanks, Rui #include <iostream> // for std::dataout #include <utility> // for std::pair #include <boost/utility.hpp> // for boost::tie #include <boost/graph/graph_traits.hpp> // for boost::graph_traits #include <boost/graph/graph_utility.hpp> #include <boost/graph/betweenness_centrality.hpp>//for boost::brandes_betweenness_centrality #include <boost/graph/adjacency_list.hpp> using namespace boost; using namespace std; typedef adjacency_list < vecS, //Store out-edges vecS, //Store vertex set undirectedS, //the graph is undirected property<edge_index_t, int> > Graph; typedef graph_traits<Graph>::vertex_descriptor Vertex; typedef graph_traits<Graph>::vertex_iterator Vertex_Iter; typedef graph_traits<Graph>::edge_descriptor Edge; typedef graph_traits<Graph>::edge_iterator Edge_Iter; typedef property_map<Graph, vertex_name_t>::type Name_Map_t; typedef property_map<Graph, edge_index_t>::type Edge_Map_t; int main(int,char*[]) { int n_vrtx = 5; //Builds graph with vertices, but no edges Graph g_star(n_vrtx); //Add edges. Graph g_star is a star add_edge(vertex(0, g_star), vertex(4, g_star), g_star); add_edge(vertex(1, g_star), vertex(4, g_star), g_star); add_edge(vertex(2, g_star), vertex(4, g_star), g_star); add_edge(vertex(3, g_star), vertex(4, g_star), g_star); Vertex_Iter vertex_iterator_begin, vertex_iterator_end; std::vector<double> centrality(n_vrtx); brandes_betweenness_centrality(g_star, centrality_map(make_iterator_property_map(centrality.begin(), get(vertex_index, g_star),double())).vertex_index_map(get(vertex_index, g_star))); for ( tie(vertex_iterator_begin, vertex_iterator_end) = vertices(g_star); vertex_iterator_begin != vertex_iterator_end; ++vertex_iterator_begin) { cout << "Vertex: " << *vertex_iterator_begin <<"\tBC: "<< centrality[*vertex_iterator_begin] << endl; } }

2 2