August 2004 - Boost-users - lists.preview.boost.org

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

Using external property map with a mutable boost.graph
by Jeff Holle 30 Aug '04

30 Aug '04

I'm using a boost.graph via: typedef boost::adjacency_list<boost::vecS,boost::vecS,boost::bidirectionalS> GraphT; In my application, I've decided to use external maps. I have discovered a problem using vertex descriptors as a key of a map. Basically, in doing a remove_vertex sequence involving vertex descriptors 5, 3, 2, I discovered that the next vertex descriptor produced by add_vertex was 4. At this point the insert into my map failed because this element already existed. Given the mutable nature of vertex descriptors, I don't see how they can be used as a key in a map. I'm contemplating two options at this point. 1. Switch from map to vector in storing my vertex property externally. 2. Switch to internal properties. My questions are: 1. Is the first option viable? As I see things, vertex descriptors are always contiguous and in the range (0..num_vertices(graph)]. Is this true? 2. Do internal "maps" avoid this type of problem?

2 1

date_time bug cvs latest vc7.1
by Gordon Smith 29 Aug '04

29 Aug '04

The following sample will not compile with the following settings (I know it has been discussed with regards to the regex library previously) - this code compiles fine in 1_31: "Character set": "Use Multi-Byte Character Set" (I am targetting win 95/98) "Treat wchar_t as Built-in Type (/Zc:wchar_t)": "No" The contrived example demonstrates why I can't turn "/Zc:wchar_t" on: #include "stdafx.h" #include <comutil.h> #include <boost/date_time/gregorian/gregorian.hpp> int _tmain(int argc, _TCHAR* argv[]) { _variant_t var("Narrow String"); return 0; } begin 666 boost_bug_001.zip M4$L#!!0````(`&A9$C&80G7MR@````\!```1````8F]O<W1?8G5G7S P,2YC M<'!5CD%+Q# 0A<\&\A^&>MD52>K5E071@R</ZDTD9-,T'6@G83I=%?&_V^Q% MO7WO8^;QK(5#SK.XPY)<VUZ94 I<PWWLD>(,,D2()/P))2,)])E/+F2:\QC! MES)B\(*9C%;6:J75.5(8ERY",TOG^P\S-/_T3<C3(CB:8?_7GF;8SDMT@E.T MB6/*C)Y^R0RE[&M7G>)D\DB;BIY3N 3W<O=P^W11T_'U;:O5EU9G[NCKISB! ME3;-HV?.[_ LC)2:[6X]X2@+$[0K?_\`4$L#!!0````(`%!6$C$O3O0P5P$` M`),#```1````8F]O<W1?8G5G7S P,2YS;&Z=D,UKPC 8QL\6^C^$GAR8DFCM MZF&'IA]CA\%0V([2CR(a)962)-*AO._WVI5ITZF'H(29XW[^]]\CRSHI)*SC1X M9:K..)CHNF023"2O-9,"I(S3'DAE]9&9-[12C1BX"-G62R7?::&[SBH@T2A* M2 `#XH40XQC!(,88(A2B:(1-U>NOG3OP`)Q<2J6G>3V?(H2=WHG@+HN%H3;Z M:NCA*"+W'D1ID$+/1Q@&89I GY!1WP_]88(':\>V.JV/B5G&7+>]QG1!14E% MP:AJ)B_,F+9D>A)1'K?9UD&RK4<N\XR;=]O##KU+)9)BQN9UE367#;RBNYII MZL34_,?(F[T1QI333%$CM:>MA2/ZV;36S?DP\Y/?TRY+RMV8<4/#7M)HMK?W M_<;$H'\UA]2,ERZZF=+F<.2GU6YF'3R=DO[-.OG45"B6,\[TU[:D_LCZ.DY8 MED_B,LQ>L:T?4$L#!!0````(`%!6$C&SGO.4R0```"P!```*````<W1D869X M+F-P<&60O6[#, R$=P-^AT,ZUT[7; 6"HEN&9.@6T!)=*U!(03]H_/:17:-+ MUR._XQW['BE;&A^="0$')"W1,$;G&7FB#"?&%\L)MY)RE;CNDUB*]F_4-GV/ M037EZU"^K_O]6Q?,A!_G/09>F1#YU>@]5%N+B<ER7*GMM@ZWWW6CDLG)?R;/ M@>O!4>.=LE-IF[9YV0)@M]E,NT6NMI?3\71 Y)$C2ZU#,H.L=0M)?@N0,&N! M,"]-<+X<WS^^NL^5KP4ANI2O25Q:W]$V3U!+`P04````" !05A(QJ,6F9;L` M```E`0``" ```'-T9&%F>"YH58_!BL,P#$3O@?S#P%Y+<R]+3WOO97] :\NQ M2V)G91F:OZ]<*&TO`FF>1J-I0E5/X7:,."%EMS3/"&FQ4L0TRI[$H^Y5>?T` MZF$<I@E&;5*N[!1U8Y="<I\8-)*"A-$J>P3A_\99E_V OZ8/CRZZ2'DV/>47 MT<5Q&(>O36A>"24[[KU-GB>^4ZDJ3.OY?:CF)L=X[JCY_UY^+B<(!Q8V"Y#W M25/)M" R>9:*O;3'([/0BAX@B46/MC .=U!+`0(4"Q0````(`&A9$C&80G7M MR@````\!```1``````````$`( ````````!B;V]S=%]B=6=?,# Q+F-P<%!+ M`0(4"Q0````(`%!6$C$O3O0P5P$``),#```1``````````$`( ```/D```!B M;V]S=%]B=6=?,# Q+G-L;E!+`0(4"Q0````(`%!6$C&SGO.4R0```"P!```* M``````````$`( ```'\"``!S=&1A9G@N8W!P4$L!`A0+% ````@`4%82,:C% MIF6[````)0$```@``````````0`@````< ,``'-T9&%F>"YH4$L%!@`````$ -``0`[ ```%$$```````` ` end

2 3

boost::thread callback copy problem
by Howard Cole 27 Aug '04

27 Aug '04

Hi, I am new to boost::thread but have come across the following problem and wondered if anyone could help... The problem is the copy overhead used by the boost::thread / boost::function0 code. The following code actually creates multiple copies of myclass rather than using a reference to myclass and due to the size of the class, this leads to a considerable overhead. I only noticed this problem because the thread kept failing due to the fact that my constructor held some socket initialisation code, which was being called multiple times. Is there a way that I can force the thread class to use references rather than copying? Looking at the code for the function library, I see that you can use boost::ref for function classes, any ideas as to how it can be used in the thread class? Thanks in advance Howard Cole www.selestial.com Example code. class myclass { public: // Lots of local data here void operator() () { do_thread_stuff(); }; // CTOR myclass(){ do_some_initialisation_stuff(); }; // DTOR ~myclass(){ do_some_cleanup_stuff(); }; // Lots of member funcs ... }; void main (void){ myclass test_instance; boost::thread test_thread(test_instance); test_thread.join(); }

3 3