- Boost-users - lists.boost.org

boost::graph adding verticies and edges whilst performing a dfs
by Daren Grant 01 Sep '04

01 Sep '04

Greetings all , I have a quick question regarding the boost graph library and depth first search operations. I have a very large graph , which has a visitor attached to the depth_first_search routine. The Visitor may add in more verticies / Edges when visiting an existing vertex in the Graph. (NOTE :: All the added verticies / edges from the visitor are guaranteed to be higher in the graph structure! i.e. the DFS algorithm would not have processed them at time of insertion. ) My question is can the depth_first_search handle changes to the Graph whilst it is performing its operation ? From my observations of the colour map used I dont think this is possible with the core depth_first_search routine in the library , could someone confirm this , and if anyone has ideas on how this can be performed I would be most grateful to hear their thoughts !

3 4

Guidelines for effective exception usage
by Stephen torri 01 Sep '04

01 Sep '04

Are there any guidelines on where and when to use exceptions? Are there any boost components that deal with exceptions? Stephen -- Email: storri(a)torri.org

11 28

internal properties and subgraphs.
by Jeffrey Holle 31 Aug '04

31 Aug '04

I've been experimenting with subgraphs. At present, they look quite useful in what I'm trying to do, but I've questions. If I add custom vertex and edge properties to my base graph, can I access these through a subgraph, using local vertex/edge descriptors? If not, is there a way of obtaining the mapping between global and local vertex/edge descriptors?

1 2

interal properites with boost.graph question
by Jeffrey Holle 31 Aug '04

31 Aug '04

I've apparently succeeded in switching from external to internal properites in my application. However, I've done things in an OOP way, and would like to know if somebody can point out potential trouble. I've a class, called Graph, that inherits from the boost::graph object. The start of its definition is: class Graph : public GraphT { public: Graph(); // Graph Data accessor methods typedef boost::property_map<GraphT, vertex_Datum_t>::type VertexData; typedef boost::property_map<GraphT, edge_Datum_t>::type EdgeData; const VertexData& getVertexData(void) const {return vertexData_;} ... private: VertexData vertexData_; }; Note the typedef of VertexData. I initialize vertexData_ in the Graph constructor like this: vertexData_ = boost::get(vertex_Datum, *this); I've numerous methods like this in Graph: Vertex DataGraph::add_vertex(LayoutVertex *pLayoutVertex) { Vertex vertex = boost::add_vertex(*this); boost::put(vertexData_,vertex,Vertex_Datum(pLayoutVertex)); return vertex; } I guess my biggest concern is initializing vertexData_ once, before the graph has any data, and keeping it around though the life of the graph. Is this safe? Also, I expect clients of this class to be able to use the operator[] method via getVertexData(). Will this work?

5 5

problem compiling with threads and stlport
by Nicholas Cain 31 Aug '04

31 Aug '04

hi, I'm new to boost, stlport and programming on linux in general, so I apologise now for any obvious beginner errors! I'm using mandrake 10 and gcc 3.3.2, and using root I created STLport 4.6.2 libraries, and then created all the boost 1.31.0 libraries using bjam -sTOOLS=gcc-stlport -sBUILD="debug release <stlport-iostream>on" install I had to have this little lot in my bashrc file to do it; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export STLPORT_VERSION=4.6.2 export STLPORT_ROOT=/home/ncain export STLPORT_LIB_DIRECTORY=/usr/local/lib export STLPORT_INCLUDE_DIRECTORY=/usr/local/include/ export PYTHON_VERSION=2.3 export PYTHON_ROOT=/usr Everything seemed to build ok, apart from an "../lib/libstlport_gcc_debug.so does not exist" error in the final part of the stlport build and a continual "warning: "_POSIX_C_SOURCE" redefined" warning during the boost build. Both the stlport and boost libraries are in /usr/local/lib ok, and building thread/test passed fine too. I altered one of the tutorial files to use _STL and also created a makefile (since bjam is a bit beyond me at the moment), and these appear as; testboost.cpp: #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <iostream> using namespace _STL; struct thread_alarm { thread_alarm(int secs) : m_secs(secs) { } void operator()() { cout << "alarm sounded..." << endl; } int m_secs; }; int main(int argc, char* argv[]) { int secs = 5; thread_alarm alarm(secs); boost::thread thrd(alarm); thrd.join(); } makefile: .PHONY: all clean ALL = testboost INCS = -I"/usr/local/include/stlport" \ -I"/usr/local/include/boost-1_31" LIBS=-L"/usr/local/lib" -lstlport_gcc -lboost_thread-gcc-mt-p -lpthread .cpp: ${CXX} ${INCS} -pthread -o $@ $^ ${LIBS} all: ${ALL} clean: ${RM} core* *.o ${RM} ${ALL} make returns this error; g++ -I"/usr/local/include/stlport" -I"/usr/local/include/boost-1_31" -pthread -o testboost testboost.cpp -L"/usr/local/lib" -lstlport_gcc -lboost_thread-gcc-mt-p -lpthread /home/ncain/tmp/ccZWBPnj.o(.text+0x4b): In function `main': : undefined reference to `boost::thread::thread[in-charge](boost::function0<void, _STL::allocator<boost::function_base> > const&)' collect2: ld returned 1 exit status make: *** [testboost] Error 1 using -lboost_thread-gcc-mt-gdp makes no difference, however changing the cpp to use the std libraries works fine (builds and runs correctly). Have I made a mistake in building the boost libraries or possibly in my makefile? thanks, nik

4 8

installing boost
by Fred J. 31 Aug '04

31 Aug '04

Hello I am stuck, here is my info, thanks much boost install steps for i686-pc-Linux debian-GNU/Linux 2.6.8 # ls /var/boost/ boost-jam-3.1.10-1-linuxx86.tgz boost_1_31_0.tar.bz2 debian:/var/boost# tar -xvzf boost-jam-3.1.10-1-linuxx86.tgz debian:/var/boost# tar -jxf boost_1_31_0.tar.bz2 debian:/var/boost/boost-jam-3.1.10-1-linuxx86# cp bjam /usr/local/bin/ debian:/var/boost/boost-jam-3.1.10-1-linuxx86# which bjam /usr/local/bin/bjam debian:~# which gcc /usr/bin/gcc debian:~# bjam -sGCC_ROOT_DIRECTORY="" Unable to load Boost.Build: could not find "boost-build.jam" --------------------------------------------------------------- Attempted search from /root up to the root and in these directories from BOOST_BUILD_PATH and BOOST_ROOT: /usr/share/boost-build. Please consult the documentation at 'http://www.boost.org'. debian:~# __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

4 4

pthread, futex_wait hang
by Matt Paindavoine. 30 Aug '04

30 Aug '04

Hello, I have been using the spirit parser library, and other boost pieces (date, test, variant, ...), along with Mozilla. I recently merged in some parts of the application that were running separately, and the program started hanging. I did a bit of searching, but couldn't find anything significantly wrong, especially since the individual parts are working correctly. The problem seems to be related to threads, as the stack indicates (cf stack at the end), and as the strace output shows here: parsing:*****************************: ) = 240 time([1093872322]) = 1093872322 futex(0x4045b860, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x4045b860, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) [... ad vitam eternam] I compiled this program using gcc (GCC) 3.4.1 (Debian 3.4.1-7) using -DBOOST_MPL_NO_PREPROCESSED_HEADERS -DBOOST_SPIRIT_DEBUG -fPIC -I/usr/X11R6/include -frtti -fexceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_root -DTRACING -g -fno-inline -I/usr/X11R6/include -DMOZILLA_CLIENT -include I don't know exactly what those threads are doing behind my back, but I'd appreciate if someone could provide some suggestion for fixing this problem. Thanks. Matt stack: #0 0x4040c791 in pthread_setcanceltype () from /lib/tls/libc.so.6 #1 0x4045b860 in __after_morecore_hook () from /lib/tls/libc.so.6 #2 0x4045aedc in ?? () from /lib/tls/libc.so.6 #3 0x00000031 in ?? () #4 0x4039ad63 in posix_memalign () from /lib/tls/libc.so.6 #5 0x00000012 in ?? () #6 0x409c91fc in ~lightweight_mutex (this=0x819eb40) at lwm_pthreads.hpp:53 #7 0x409c9d24 in ~sp_counted_base_impl (this=0x819eb40) at nsCXExpRecord.cpp:219 #8 0x409c96e2 in boost::detail::sp_counted_base::destruct (this=0x819eb40) at shared_count.hpp:115 #9 0x409b2a7e in boost::detail::sp_counted_base::weak_release (this=0x819eb40) at shared_count.hpp:173 #10 0x409bd6de in boost::detail::weak_count::operator= (this=0x40b3bb3c, r=@0x41749188) at shared_count.hpp:492 #11 0x409bd68f in boost::weak_ptr<boost::spirit::impl::grammar_helper<boost::spirit::grammar<cx::FooFooRecordGrammar<cx::FooConfigFooRecordGrammar>, boost::spirit::closure_context<cx::FooFooRecordClosure<cx::FooConfigFooRecordGrammar> > >, cx::FooFooRecordGrammar<cx::FooConfigFooRecordGrammar>, boost::spirit::scanner<__gnu_cxx::__normal_iterator<char const*, std::string>, boost::spirit::scanner_policies<boost::spirit::iteration_policy, boost::spirit::match_policy, boost::spirit::action_policy> > > >::operator=<boost::spirit::impl::grammar_helper<boost::spirit::grammar<cx::FooFooRecordGrammar<cx::FooConfigFooRecordGrammar>, boost::spirit::closure_context<cx::FooFooRecordClosure<cx::FooConfigFooRecordGrammar> > >, cx::FooFooRecordGrammar<cx::FooConfigFooRecordGrammar>, boost::spirit::scanner<__gnu_cxx::__normal_iterator<char const*, std::string>, boost::spirit::scanner_policies<boost::spirit::iteration_policy, boost::spirit::match_policy, boost::spirit::action_policy> > > > (this=0x40b3bb38, r=@0x41749184) at weak_ptr.hpp:87 #12 0x409bc67a in grammar_helper (this=0x41749170, p=@0x40b3bb38) at grammar.ipp:156 [ goes further up, I don't know if it will help... ]

2 2

BLL and member variables
by Mattias Brändström 30 Aug '04

30 Aug '04

Hello, I really like the BLL and would like to use it as much as possible. I have run into a small problem though. My code looks like this: #include <boost/lambda/bind.hpp> #include <boost/lambda/lambda.hpp> #include <map> #include <vector> class A { public: A(int a, int b) : a_(a), b_(b) { } int a_; int b_; }; int main() { using namespace boost::lambda; std::vector<A> v; v.push_back(A(1, 2)); typedef std::map<int, int> Map; Map m; for_each(v.begin(), v.end(), bind(&Map::insert, std::make_pair(bind(&A::a_, _1), bind(&A::b_, _1)))); return 0; } What I want to do is to populate a map with the information from the vetctor v. For each element in v I want to insert a value and a key into the map something like this: void operator()(const A& a) const { m_.insert(std::make_pair(a.a_, a.b_)); } I found some information on how to use member variables as targets in the BLL documentation and that is what I have tried to use in the code above. It won't compile however, using g++ I get the following error: g++ -c -o test.o test.cpp test.cpp: In function `int main()': test.cpp:27: error: no matching function for call to `bind(<unknown type>, std::pair<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int A::*, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int A::*, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >)' scons: *** [test.o] Error 1 scons: building terminated because of errors. If someone here has any ideas of how to accomplish this it would be really nice! Thanks in advance! Regards, Mattias

2 1

downloading problems
by Fred J. 30 Aug '04

30 Aug '04

Hello I am trying to download a boost library from http://sourceforge.net/project/showfiles.php?group_id=7586 where the library name suppost to be, there is [show only this release] instead, the wholl page, all the library names are not listed. any body is having the same problem or it is just me thanks _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

2 1

Re: [boost] Re: MPL vector size limit
by Aleksey Gurtovoy 30 Aug '04

30 Aug '04

Arkadiy Vertleyb writes: > Sorry to repeat this question, but I think I am missing somehing here: > > Do I understand correctly that it's not possible in the current > version of MPL to use mpl::vector of a size larger than 50? It is possible. As I tried to explain in my previous reply, you can pre-generate the coressponding headers up to whatever limit you choose. You can also generate the sequence "on the fly", although that's less efficient. > > If this is not correct, what exactly do I have to do to use, for > example, mpl::vector97<...>? #include "boost/mpl/vector/vector50.hpp" #include "boost/mpl/aux_/config/vector.hpp" #include "boost/mpl/aux_/config/ctps.hpp" #include "boost/preprocessor/iterate.hpp" #include "boost/config.hpp" namespace boost { namespace mpl { #define BOOST_PP_ITERATION_PARAMS_1 \ (3,(51, 100, "boost/mpl/vector/aux_/numbered.hpp")) #include BOOST_PP_ITERATE() }} > > If this _is_ correct, I would like to make a feature request for it > to be increased, since the limit of 50 doesnt seem to be high enough > (I am making this statement in conjunction with the need of my > typeof emulation lib, but I am kind of surprized this question > hasn't yet popped up in other contexts, or has it?). We are using sequences of ~70 elements here at work (mostly in context of FSMs), but then we simply pre-generate them locally. Increasing the default limit to, let's say, 100 elements means plus ~120 KB to the size of the distribution, and I'm not sure the need is widespread enough to make everybody pay for it. > In particular, isn't it possible to just get it fully controlled by > BOOST_MPL_LIMIT_VECTOR_SIZE without any limitations whatsoever? Once again, tweaking BOOST_MPL_LIMIT_VECTOR_SIZE is a dubious practice. You can get as long of a sequence as you want with the technique demostrated in the example above, with a caveat that it's going to be less efficient than using pre-generated headers. -- Aleksey Gurtovoy MetaCommunications Engineering

2 1