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

Re: [Boost-users] Container iteration macro that is equivalent tohandcoded iteration?
by John Femiani 12 Oct '07

12 Oct '07

> -----Original Message----- > From: John Femiani > Sent: Wednesday, October 10, 2007 3:16 PM > To: 'boost-users(a)lists.boost.org' > Subject: RE: [Boost-users] Container iteration macro that is equivalent > tohandcoded iteration? > > > > -----Original Message----- > > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > > bounces(a)lists.boost.org] On Behalf Of Michael Marcin > > Sent: Wednesday, October 10, 2007 1:07 PM > > To: boost-users(a)lists.boost.org > > Subject: Re: [Boost-users] Container iteration macro that is equivalent > > tohandcoded iteration? > > > > Erik wrote: > > > I have a lot of handcoded loops that look something like this: > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > #include <vector> > > > > > > void f(float); > > > void g(std::vector<float> const & v) { > > > std::vector<float>::const_iterator const v_end = v.end(); > > > for (std::vector<float>::const_iterator it = v.begin(); it != > v_end; > > ++it) > > > f(*it); > > > } > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > > > > I need to replace it with something equivalent but simpler. I tried > > > BOOST_FOREACH (from boost-1.34): > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > #include <boost/foreach.hpp> > > > > > > #include <vector> > > > > > > void f(float); > > > void g(std::vector<float> const & v) { > > > BOOST_FOREACH(float i, v) > > > f(i); > > > } > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > > > > But when I compared the assembly output of this with that of the > > > handcoded version I discovered that the boost version is more > > > complicated, so I tried to create something better myself, with the > > > requirement that the generated code is not allowed to be any more > > > complicated than that of the handcoded loop. The following is the best > I > > > could think of right now: > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > #define iterate_vector_const(value_type, it, v) > \ > > > for > \ > > > (struct { > \ > > > std::vector<value_type>::const_iterator current; > \ > > > std::vector<value_type>::const_iterator const end; > \ > > > value_type const & operator*() {return *current;} > \ > > > } it = {v.begin(), v.end()}; > \ > > > it.current != it.end; > \ > > > ++it.current) > \ > > > > > > #include <vector> > > > > > > void f(float); > > > void g(std::vector<float> const & v) { > > > iterate_vector_const(float, it, v) > > > f(*it); > > > } > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > > > > I looked at the difference between my macro and the handcoded loop: > > > $ diff -U2 iteration-handcoded-g++-4.2.0-O3.S iteration- > iterate_vector- > > g++-4.2.0-O3.S > > > --- iteration-handcoded-g++-4.2.0-O3.S 2007-10-07 19:38:56.000000000 > > +0200 > > > +++ iteration-iterate_vector-g++-4.2.0-O3.S 2007-10-07 > > > 20:00:53.000000000 +0200 > > > @@ -1,3 +1,3 @@ > > > - .file "iteration-handcoded.cc" > > > + .file "iteration-iterate_vector.cc" > > > .text > > > .align 2 > > > @@ -18,7 +18,7 @@ > > > .LCFI4: > > > movl 8(%ebp), %eax > > > - movl 4(%eax), %esi > > > movl (%eax), %ebx > > > - cmpl %ebx, %esi > > > + movl 4(%eax), %esi > > > + cmpl %esi, %ebx > > > je .L4 > > > .p2align 4,,7 > > > > > >>From this I conclude that my macro is as good as a handcoded loop. > > > (Although I of course wonder why the compiler chose to move "movl > > > 4(%eax), %esi" further down and swap the parameters of cmpl from > "%ebx, > > > %esi" to "%esi, %ebx".) > > > > > > But my macro is not as versatile as BOOST_FOREACH. Is there any way to > > > improve it? In particular, is it possible get rid of the macro > parameter > > > value_type? Is it possible to make it work with other containers than > > > vectors, as long as they define const_iterator/iterator, begin, end > and > > > value_type? Something like this maybe: > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > #define iterate_container_const(it, v) > \ > > > for > \ > > > (struct { > \ > > > typeof(v)::const_iterator current; > \ > > > typeof(v)::const_iterator const end; > \ > > > typeof(v)::value_type const & operator*() {return *current;} > \ > > > } it = {v.begin(), v.end()}; > \ > > > it.current != it.v_end; > \ > > > ++it.current) > \ > > > > > > #include <vector> > > > > > > void f(float); > > > void g(std::vector<float> const & v, std::list<float> const & l) { > > > iterate_containter_const(it, v) > > > f(*it); > > > iterate_containter_const(it, l) > > > f(*it); > > > } > > > > > > //////////////////////////////////////////////////////////////////////// // > > //// > > > > > > Or is it possible to configure BOOST_FOREACH to be as efficient as my > > macro? > > > > I don't know but that is a good question. > > > > I considered using BOOST_FOREACH until I checked its generated output... > > which was worse than std::for_each with a boost::bind which was worse > > than std::for_each with a hand coded functor which was worse than a hand > > coded for loop like yours above. > > > > - Michael Marcin > > > > p.s. Compilers make me sad > > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > I think you will need to pass SOME type unless you are comfortable with > BOOST_AUTO or BOOST_TYPEOF. I think the problem is on some compilers they > require each type to be 'registered'. > > Maybe if you use a NEXT macro as well things will work out, because you > can put multiple braces in the next macro. > > #define FOREACH(X, COL, COLT) \ > { \ > COLT& __col__ = (COL); \ > for (iterator_type<COLT>::type __i__ = begin(__col__); \ > __i__ != end(__col__);\ > ++__i__) \ > { \ > X = *__i__; \ > { > > #define NEXT() \ > }\ > }\ > } > > > I haven't tried this, but it seems like one could do: > > #define FOREACH(X, COL) \ > { \ > BOOST_TYPEOF(COL)& __col__ = (COL); \ > BOOST_AUTO(__cur__, boost::begin(__col__)); > BOOST_AUTO(__end__, boost::end(__col__)); > for (; __cur__ != __end__; ++__cur__) \ > { \ > X = *__cur__; \ > { > > #define NEXT() \ > }\ > }\ > } > > Then you could use it like: > > vector<int> vec; > > FOREACH(int x, vec){ > > //do something with x > > }NEXT(); > > Or if BOOST_AUTO doesn't work it is > > vector<int> vec; //vector<int> does not have a comma in the type name! > > FOREACH(int x, vec, vector<int>) { > > //do something with x > > }NEXT(); > > > I have no idea how well BOOST_AUTO will work though. You would also need a > TPL version I think. > > IN my own code I have a special concern because I deal with half_edge > structures where begin()==end() and I need to do a bottom testing loop. > In these cases I made iteration macros for each container: I.e. > > MY_FOREACH_VERTEX_EDGE(e, vertex){ > //e is an edge iterator > }MY_NEXT_VERTEX_EDGE() > > > I found that to be readable. I did not use BGL stuff because I did not > know how to deal with begin() == end(). > > > -- John That is, unless you can understand the magic that makes BOOST_FOREACH work. :) -- John

2 1

Container iteration macro that is equivalent to handcoded iteration?
by Erik 12 Oct '07

12 Oct '07

I have a lot of handcoded loops that look something like this: ////////////////////////////////////////////////////////////////////////////// #include <vector> void f(float); void g(std::vector<float> const & v) { std::vector<float>::const_iterator const v_end = v.end(); for (std::vector<float>::const_iterator it = v.begin(); it != v_end; ++it) f(*it); } ////////////////////////////////////////////////////////////////////////////// I need to replace it with something equivalent but simpler. I tried BOOST_FOREACH (from boost-1.34): ////////////////////////////////////////////////////////////////////////////// #include <boost/foreach.hpp> #include <vector> void f(float); void g(std::vector<float> const & v) { BOOST_FOREACH(float i, v) f(i); } ////////////////////////////////////////////////////////////////////////////// But when I compared the assembly output of this with that of the handcoded version I discovered that the boost version is more complicated, so I tried to create something better myself, with the requirement that the generated code is not allowed to be any more complicated than that of the handcoded loop. The following is the best I could think of right now: ////////////////////////////////////////////////////////////////////////////// #define iterate_vector_const(value_type, it, v) \ for \ (struct { \ std::vector<value_type>::const_iterator current; \ std::vector<value_type>::const_iterator const end; \ value_type const & operator*() {return *current;} \ } it = {v.begin(), v.end()}; \ it.current != it.end; \ ++it.current) \ #include <vector> void f(float); void g(std::vector<float> const & v) { iterate_vector_const(float, it, v) f(*it); } ////////////////////////////////////////////////////////////////////////////// I looked at the difference between my macro and the handcoded loop: $ diff -U2 iteration-handcoded-g++-4.2.0-O3.S iteration-iterate_vector-g++-4.2.0-O3.S --- iteration-handcoded-g++-4.2.0-O3.S 2007-10-07 19:38:56.000000000 +0200 +++ iteration-iterate_vector-g++-4.2.0-O3.S 2007-10-07 20:00:53.000000000 +0200 @@ -1,3 +1,3 @@ - .file "iteration-handcoded.cc" + .file "iteration-iterate_vector.cc" .text .align 2 @@ -18,7 +18,7 @@ .LCFI4: movl 8(%ebp), %eax - movl 4(%eax), %esi movl (%eax), %ebx - cmpl %ebx, %esi + movl 4(%eax), %esi + cmpl %esi, %ebx je .L4 .p2align 4,,7 >From this I conclude that my macro is as good as a handcoded loop. (Although I of course wonder why the compiler chose to move "movl 4(%eax), %esi" further down and swap the parameters of cmpl from "%ebx, %esi" to "%esi, %ebx".) But my macro is not as versatile as BOOST_FOREACH. Is there any way to improve it? In particular, is it possible get rid of the macro parameter value_type? Is it possible to make it work with other containers than vectors, as long as they define const_iterator/iterator, begin, end and value_type? Something like this maybe: ////////////////////////////////////////////////////////////////////////////// #define iterate_container_const(it, v) \ for \ (struct { \ typeof(v)::const_iterator current; \ typeof(v)::const_iterator const end; \ typeof(v)::value_type const & operator*() {return *current;} \ } it = {v.begin(), v.end()}; \ it.current != it.v_end; \ ++it.current) \ #include <vector> void f(float); void g(std::vector<float> const & v, std::list<float> const & l) { iterate_containter_const(it, v) f(*it); iterate_containter_const(it, l) f(*it); } ////////////////////////////////////////////////////////////////////////////// Or is it possible to configure BOOST_FOREACH to be as efficient as my macro?

10 17

[review] Exception - review period extended
by Tobias Schwinger 12 Oct '07

12 Oct '07

The review period of the proposed Exception library has been extended until October 20th. Although several people seemed interested in the submission, we only have two votes, so far. So we really need more votes. Further, I'm concerned about some potential issues, which I wouldn't want to bless into Boost without being sure there has been a thorough investigation (see below). So, I want to encourage you to evaluate the submission, in particular regarding the following questions: 1. Should the library be accepted as a Boost library? For a guideline on what to include in your evaluation see http://www.boost.org/more/formal_review_process.htm 2. Is the design of the 'enable_error_info' function (see http://www.revergestudios.com/boost-exception/boost-exception.htm#existing_… and http://www.revergestudios.com/boost-exception/boost-exception.htm#enable_er… ), using multiple inheritance, really sound? 3. Does the current implementation use appropriate data structures? We are looking forward to your reviews! Regards, Tobias Schwinger - Review Manager -

2 1

[serialization] shared libraries & extended_type_info registration
by Vincent Agnus 12 Oct '07

12 Oct '07

Hi, I have some trouble about extended_type_info registration using BOOST_CLASS_EXPORT macro with shared library. Indeed an assertion forbides the registration of the same extended_type_info many times. This cases occurs when defining serialization of derivated classes in different libraries for example considers the 2 libraries : * the first one define a class and its serialization scheme * the second one define a class derived from the class in the first libs and its serialization scheme A program using this two libraries to serialize classes raise an assertion at runtime due to double registration of the base class [ file serialization/extended_type_info.cpp line 74 // make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end()); ] Here the detail implementation of libraries LIB1 * files : Base.hpp ; Base.cpp defining a base class ( no serialization code here) * file : BaseSerilization.hxx which contains the definition of the non intrusive template function serialize ( no macro BOOST_CLASS_EXPORT here ) * file BaseSerilizationInstanciation.cpp which explicit instanciate the previous function with a fixed Archive class, this file also contain the macro BOOST_CLASS_EXPORT(Base) LIB2 * file Derivated.hpp, Derivated.cpp defining derivated class from Base ( no serialization code here) * file : DerivatedSerilization.hxx which contains the definition of the non intrusive template function serialize ( no macro BOOST_CLASS_EXPORT here ) ** #include "lib1/BaseSerilization.hxx" ** in fonction serialize .... use of base_object< lib1::Base > * file DerivatedInstanciation.cpp which explicit instanciate the previous function with a fixed Archive class, this file also contain the macro BOOST_CLASS_EXPORT(Derivated) a program using these 2 libraries raise an assertion file serialization/extended_type_info.cpp line 74. Indeed the macro BOOST_CLASS_EXPORT(Base) register the extended_type_info of Base. the macro BOOST_CLASS_EXPORT(Derivated) register the extended_type_info of Base *and* the void_caster register in serialize(... Derivated ...) register *again* Base class raising the assertion. So I have some questions 1. Is my design correct ? My programme work fine (Linux&Windows) in release mode. 2. why forbides multi-registration of the same extended_type_info ? 3. what is the interest using std::multiset for unique element instead std::set for tkmap::m_map type ? Regards, Vincent Agnus

5 9

[signal,bind] upgrade problem from 1.33 to 1.34
by David Angelo 12 Oct '07

12 Oct '07

Hi folks, I have a problem with upgrading from boost version 1.33 to 1.34. My code runs fine with 1.33, but when compiling and linking againt 1.34 I get the following runtime error (backtrace): <backtrace> #0 0x81d4c9b2 in void boost::function1<void, float, std::allocator<void> >::ass ign_to<boost::_bi::bind_t<void, boost::_mfi::mf1<void, fpCTPart, float>, boost:: _bi::list2<boost::_bi::value <fpCTPart*>, boost::arg<1> (*)()> > >(boost::_bi::bi nd_t<void, boost::_mfi::mf1<void, fpCTPart, float>, boost::_bi::list2<boost::_bi ::value<fpCTPart*>, boost::arg<1> (*)()> >)::stored_vtable () from /home/david/eclipseM6/toolManagement/lib/libfpCTToolPack.so #1 0xb4438841 in boost::function0<void, std::allocator<void> >::clear ( this=0xa1a03fc) at /usr/include/boost/function/function_template.hpp:388 #2 0xb4438879 in ~function0 (this=0xa1a03fc) at /usr/include/boost/function/function_template.hpp:313 #3 0xb443889d in ~function (this=0xa1a03fc) at /usr/include/boost/function/function_base.hpp:92 #4 0x81a34c39 in ~holder (this=0xa1a03f8) at /home/david/apps/boost_1_34_1/include/boost-1_34_1/boost/any.hpp:106 #5 0x81137b41 in boost::signals::detail::named_slot_map::insert () from /home/david/apps/boost_1_34_1/lib/libboost_signals-gcc41-1_34_1.so.1.34. 1 #6 0x8113b562 in boost::signals::detail::signal_base_impl::connect_slot () from /home/david/apps/boost_1_34_1/lib/libboost_signals-gcc41-1_34_1.so.1.34. 1 #7 0x81a36e58 in boost::signal0<void, boost::last_value<void>, int, std::less<i nt>, boost::function<void ()(), std::allocator<void> > >::connect ( this=0x82eac060, in_slot=@0xbfe145f0, at=boost::signals::at_back) ---Type <return> to continue, or q <return> to quit---bt at /home/david/apps/boost_1_34_1/include/boost-1_34_1/boost/signals/signal_template.hpp:286 #8 0x81b359f6 in fpCTPart::initPart (this=0x82eaa7f0) at /home/david/eclipseM6/toolManagement/extensions/fpCTToolPack/parts/src/fpCTPart.cpp:173 </backtrace> Line 173 in fpCTPart.cpp is: geomNode->sigPreLoad.connect(boost::bind(&fpCTPart::slotFilePreLoaded, this)); Are there any changes between these to versions in the bind/signal library? (Are they not backward compatible?) Thanks in advance. Regards, David

1 0

[ptr_map]iterator::reference is not a reference
by Bill Buklis 11 Oct '07

11 Oct '07

I found what seems to be an inconsistency in ptr_map in version 1.34.1 versus 1.33.1. The "reference" typedef in 1.34.1 does not appear to be a reference. The following code illustrates what I mean: typedef std::map<int, int> STDMAP; typedef boost::ptr_map<int, int> PTRMAP; bool isrefstdmap = boost::is_reference<STDMAP::iterator::reference>::value; bool isrefstdbase = boost::is_reference<STDMAP::reference>::value; bool isrefptrmap = boost::is_reference<PTRMAP::iterator::reference>::value; bool isrefptrbase = boost::is_reference<PTRMAP::reference>::value; In version 1.33.1 all bool values equate to true, while in 1.34.1 ptr_map evaluates to false. In case the compiler makes a difference, I'm using VC++ 2005. -- Bill Buklis --

1 0

[boost][range] fusion::begin and boost::begin dont play nice
by John Femiani 11 Oct '07

11 Oct '07

I am using g++ (GCC) 3.4.2 (mingw-special) and when I use the namespace boost::fusion it causes boost range to break. Consider the toy program 'main.cpp', which is attached and also listed below: ----------------------------------------------------------------------- #include <iostream> using namespace std; #include <boost/fusion/sequence/container/vector.hpp> #include <boost/range.hpp> #include <list> int main() { using namespace boost::fusion; using namespace boost; std::list<int> ints; typedef boost::range_iterator<std::list<int> >::type iterator_t; for (iterator_t i = begin(ints); i != end(ints); ++i){ cout << * i << endl; } return 0; } -------------------------------------------------------------------- This program fails to compile with many errors, the first is C:/MSYS/1.0/include/boost/fusion/sequence/intrinsic/begin.hpp:56: error: invalid use of undefined type `struct boost::fusion::extension::begin_impl<boost::fusion::non_fusion_tag>::app ly<const std::list<int, std::allocator<int> > >' If I remove 'using namespace boost::fusion' then everything compiles. This toy program demonstrates an error I got when trying to compile a function that involved both a fusion::vector and std::list. It was easy to work around it in my case by explicitly saying boost::fusion::begin instead of using the namespace, but I suspect that this is still a bug. Please let me know if I misunderstood the correct way to use fusion or range. Thanx, -- John

3 5

Assigning a var() to another var() in a lambda function
by Peter Waller 11 Oct '07

11 Oct '07

Why does this not compile? Should it? It seems quite similar to code found in the section `Naming delayed constants and variables' in the manual at http://www.boost.org/doc/html/lambda/le_in_details.html #include <lambda/lambda.hpp> using namespace boost::lambda; float i = 5, j = 0; var_type<float>::type vi(var(i)), vj(var(j)); #line 172 (vi = vj); The error I get: /usr/include/boost/lambda/detail/lambda_functor_base.hpp: In member function 'boost::lambda::identity<Float_t&>& boost::lambda::identity<Float_t&>::operator=(const boost::lambda::identity<Float_t&>&)': /usr/include/boost/lambda/detail/lambda_functor_base.hpp:23: error: non-static reference member 'Float_t& boost::lambda::identity<Float_t&>::elem', can't use default assignment operator /usr/include/boost/lambda/detail/lambda_functors.hpp: In member function 'boost::lambda::lambda_functor<boost::lambda::identity<Float_t&> >& boost::lambda::lambda_functor<boost::lambda::identity<Float_t&> >::operator=(const boost::lambda::lambda_functor<boost::lambda::identity<Float_t&> >&)': /usr/include/boost/lambda/detail/lambda_functors.hpp:113: note: synthesized method 'boost::lambda::identity<Float_t&>& boost::lambda::identity<Float_t&>::operator=(const boost::lambda::identity<Float_t&>&)' first required here zzNtuple.C: In function 'int main(int, char**)': zzNtuple.C:173: note: synthesized method 'boost::lambda::lambda_functor<boost::lambda::identity<Float_t&> >& boost::lambda::lambda_functor<boost::lambda::identity<Float_t&> >::operator=(const boost::lambda::lambda_functor<boost::lambda::identity<Float_t&> >&)' first required here make: *** [zzNtuple] Error 1 g++ (GCC) 4.1.2 boost 1.34.1 Thanks in advance, - Peter

1 0

Boost 1.35?
by Matt Wharton 11 Oct '07

11 Oct '07

Hello, Does anyone have a _rough_ timetable for when boost version 1.35 will be formally released? Apologies in advance if this question has already been answered or if this is the wrong venue for it. Thanks, -Matt

2 1

Re: [Boost-users] Boost Spirit and C++/CLI
by Hansi Hansi 10 Oct '07

10 Oct '07

What is exactly the error? Which project type you have? What is your entrypoint? Best regards Hansjörg __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach! Mehr Infos unter http://produkte.web.de/club/?mc=021131

2 1

Re: [Boost-users] regex_search in std::string
by Troy Alexander 10 Oct '07

10 Oct '07

Thanks. That did it. I was focusing on the string to match not the return type. Makes since that they need to be the same type. Troy -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, October 10, 2007 2:44 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] regex_search in std::string Troy Alexander wrote: > The 1st regex_search looking at input_line char[] works Ok it's the > 2nd one looking at date_and_time_s std::string that gets the error. > If I remark out the 2nd one the program builds and I watch the > input_line doing what it should in the debugger. > > Also this code used to work before I upgraded from Visual C++6 to > Visual C++8 and from bost_1_33_1 to boost_1_34_0. I don't know if it > was the change in compiler or the boost lib that broke this. In VC6 this worked "by accident" because const char* and std::string::const_iterator were the same type. That's not true in general, and you should use boost::smatch as the match_results type for use with std::string's. HTH, John. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[BGL] maximum flow through push_relabel_max_flow
by "Alejandro M. Aragón" 10 Oct '07

10 Oct '07

Hello all, I've been working with the Edmunds & Karp maximum flow algorithm in the BGL for some time without any problems. However, I realized that I could do better in time complexity by moving to the push_relabel_max_flow algorithm so I gave it a try. I've been trying to figure out what the problem with my code is for the entire day without success. I was wondering if someone could tell me what is my mistake. It is a very simple problem, four vertices, four edges, the result from the algorithm should be two: 2--------1 | | | | | | 0--------3 Source is 0, target is 1, all edges have unit capacity. The code is: void compute_max_flow(Graph* g_) { // obtain number of vertices in undirected graph size_t n = num_vertices(*g_); typedef adjacency_list_traits<vecS, vecS, directedS> Traits; typedef adjacency_list<listS, vecS, directedS, property<vertex_index_t, int>, property<edge_capacity_t, int, property<edge_residual_capacity_t, int, property<edge_reverse_t, Traits::edge_descriptor> > > > FlowGraph; typedef graph_traits<FlowGraph>::edge_descriptor EdgeFlow; FlowGraph g(num_vertices(*this->g_)); property_map<FlowGraph, vertex_index_t>::type indexmap = get(vertex_index, g); property_map<FlowGraph, edge_capacity_t>::type capacity = get(edge_capacity, g); property_map<FlowGraph, edge_reverse_t>::type rev = get(edge_reverse, g); property_map<FlowGraph, edge_residual_capacity_t>::type residual_capacity = get(edge_residual_capacity, g); Traits::vertex_descriptor s, t; EdgeFlow e1,e2; bool in1,in2; // add edges, reverse edges and capacities to new graph for flow computation edge_iter ei,ei_end; for (tie(ei,ei_end) = edges(*g_); ei != ei_end; ++ei) { // obtain vertices in the original graph vertex u = source(*ei, *g_); vertex v = target(*ei, *g_); // insert edges in new graph and add unit capacities tie(e1, in1) = add_edge(u,v,g); tie(e2, in2) = add_edge(v,u,g); if(in1 && in2) { // assign reverse edges to property map rev[e1] = e2; rev[e2] = e1; capacity[e1] = 1; capacity[e2] = 0; } } graph_traits<FlowGraph>::vertex_iterator vvi,vvi_end; for(tie(vvi,vvi_end) = vertices(g); vvi!=vvi_end; ++vvi) { cout<<"index -> "<<indexmap[*vvi]<<endl; } graph_traits<FlowGraph>::edge_iterator eei,eei_end; for(tie(eei,eei_end) = edges(g); eei!=eei_end; ++eei) { cout<<"edge -> "<<*eei<<endl; cout<<"capacity -> "<<capacity[*eei]<<endl; cout<<"rev -> "<<rev[*eei]<<endl; } int flow = push_relabel_max_flow(g, 0, 1, capacity, residual_capacity, rev, indexmap); cout<<"flow -> "<<flow<<endl; } Results in: index -> 0 index -> 1 index -> 2 index -> 3 edge -> (0,2) capacity -> 1 rev -> (2,0) edge -> (0,3) capacity -> 1 rev -> (3,0) edge -> (1,2) capacity -> 1 rev -> (2,1) edge -> (1,3) capacity -> 1 rev -> (3,1) edge -> (2,0) capacity -> 0 rev -> (0,2) edge -> (2,1) capacity -> 0 rev -> (1,2) edge -> (3,0) capacity -> 0 rev -> (0,3) edge -> (3,1) capacity -> 0 rev -> (1,3) flow -> 0 I would appreciate any inputs on this. Thank you, a²

2 5

Usage of Transitive_closure().
by Ning Ruan 10 Oct '07

10 Oct '07

my code to use transitive_closure(): Graph tc; VertexIndexMap index_map = get(&VertexProp::id, g); vector<Vertex> to_tc_vec(num_vertices(g)); iterator_property_map<Vertex*, VertexIndexMap, Vertex, Vertex&> g_to_tc_map(&to_tc_vec[0], index_map); transitive_closure(graph, tc, g_to_tc_map, (index_map)); I use print_graph(tc, get(&VertexProp::id, tc) to print the transitive graph, then it shows: 0 --> 0 0 0 0 0 0 0 0 0 --> 0 0 0 --> 0 --> 0 0 0 0 0 0 0 0 0 --> 0 --> 0 --> 0 0 0 0 --> 0 0 0 0 0 0 0 0 the result miss the id of vertex, what 's the problem. my original graph g is correcet: 0 --> 1 2 3 1 --> 4 5 2 --> 3 --> 6 7 4 --> 5 --> 6 --> 1 7 --> 0

3 4

regex_search in std::string
by Troy Alexander 10 Oct '07

10 Oct '07

I am struggling with a regex in some code of mine. I want to use regex_search to look for a match in a std::string, but my code will not build. This is a snippet of what I am trying to do. using namespace std; string in_file_name_s; string date_and_time_s; string day_s; char input_line[5000]; boost::regex re_date_time("(.*-.*-.*:.*:.*),.*,.*,.*,.*,.*,.*,.*,.*,"); boost::regex re_pices_date_time("(.*)\\-(.*)\\-(.*) (.*)"); boost::cmatch match; while (inFile.getline(input_line , 5000)) { if (boost::regex_search(input_line, match , re_date_time )) { date_and_time_s = match[1]; if (boost::regex_search(date_and_time_s , match , re_pices_date_time )) { day_s = match[1]; } } } When I compile I get the following error error C2784: 'bool boost::regex_search(const std::basic_string<charT,ST,SA> &,const boost::basic_regex<charT,traits> &,boost::regex_constants::match_flag_type)' : could not deduce template argument for 'const boost::basic_regex<charT,traits> &' from 'boost::cmatch' The 1st regex_search looking at input_line char[] works Ok it's the 2nd one looking at date_and_time_s std::string that gets the error. If I remark out the 2nd one the program builds and I watch the input_line doing what it should in the debugger. Also this code used to work before I upgraded from Visual C++6 to Visual C++8 and from bost_1_33_1 to boost_1_34_0. I don't know if it was the change in compiler or the boost lib that broke this. Thanks in advance for your help. Troy

2 1

Re: [Boost-users] Boost::regex causes runtime errors with CLR
by Hansi Hansi 10 Oct '07

10 Oct '07

Hello, In VS2005 is a problem with the Initializing of the CRT when you have a .net application. Normally it helps when you use as entry point '?mainCRTStartupStrArray@@$$FYMHP$01AP$AAVString@System@@@Z'. I hope this helps. Best regards Hansjörg _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

2 1

Boost::regex causes runtime errors with CLR
by Rajib 09 Oct '07

09 Oct '07

Hi, I'm trying to use boost::regex with a "Windows Forms Application" in Visual Studio 2005. Everything works fine with normal C++, and even using a "CLR Console Application." But when I use the "Windows Form Application" template the program crashes while initializing variables. Basically I take code like: #include <boost/regex.hpp> using boost::regex; using boost::regex_search; bool h() { return regex_search("asdfasdf",regex("sd")); } put it in a separate file, turn off precompiled headers for that file, and never actually call h(). The program crashes instantly with a debug assertion failed at dbgheap.c/Line 1414/_CrtIsValidHeapPointer. The call stack looks like: ... msvcr80d.dll!__dllonexit(int (void)* func=0x00446110, void (void)* * * pbegin=0x0012eab8, void (void)* * * pend=0x0012eab0) Line 273 + 0x11 bytes C temp.exe!_onexit(int (void)* func=0x00446110) Line 110 + 0x11 bytes C temp.exe!atexit(void (void)* func=0x00446110) Line 127 + 0x9 bytes C temp.exe!boost::re_detail::`dynamic initializer for 'block_cache''() Line 189 + 0x2b bytes C++ ... It does this whether I compile the file with regex with the /clr flag or not (although the /clr flag gives a lot of errors, one of which isn't about converting fastcall to stdcall: include\boost/shared_ptr.hpp(92) : warning C4793: 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' Thanks, Rajib

1 0

Boost Spirit and C++/CLI
by Jason Stewart 09 Oct '07

09 Oct '07

Has anyone tried using boost spirit with C++/CLI? I have a library that uses Spirit internally to parse a file. The library is built as an unmanaged C++ static library. I then link that to a managed C++/CLI application but when I try to parse the file I get heap corruption. The corruption seems to happen near an #ifdef for BOOST_SPIRIT_THREADSAFE so I tried to define that for the build of the library and the application. Unfortunately it now fails to initialize correctly and dies on startup. Has anyone done this before? Thanks, Jason Stewart

1 0

boost::serialization XSD support
by Juhasz, Zoltan (IT) 09 Oct '07

09 Oct '07

Hi, I've got a pretty strange problem. We are using boost::serialization library to serialize arbitrary structs into XML. That is working pretty good. Our problems are: - we also need to generate schema files (XSD) for the archive file, since this XML archive file is going to be used by other programs (e.g. written in Java etc.), and - the unserialization part should be validated through the schema file. Currently, the boost::serialization library can serialize / deserialize our structs to XML just fine, but: How can we add XSD generation support? How can we 'force' boost::serialization to validate the XML file through an schema file (XSD)? PS: Unfortunately, the automatic generation of the XSD file is a strict requirement, that is why we cannot use regular XML <> C++ object mapping tools, where the C++ codes are generated by an external tool from a schema (XSD) file. PS2: If you know other third party tools that can solve the above mentioned problem, please feel free to write. Thank you in advance! Best Regards, Zoltan Juhasz Morgan Stanley | Technology | Budapest Zoltan dot Juhasz at MorganStanley dot com -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

2 1

how to schedule nodes in graph
by Suresh Gupta 09 Oct '07

09 Oct '07

Hi, I want to do the following: I have a graph in boost. Now I want to schedule the graph nodes in topological order as follows: 1. The nodes which do not have any parents are to be scheduled in first cycle. Record the list of these nodes. 2. Remove already recorded nodes (in step 1) from the graph. 3. Repeat 1 and 2 on the remaining graph and so on. How to do the above? I need functions: 1. Get all nodes which do not have parents. 2. To remove the nodes from graph. Please suggest me about the functions in boost so do the same. Thanks, Suresh

2 3

Boost::Regex question
by Dima Kagan 09 Oct '07

09 Oct '07

Hi, I'm currently evaluating the Regex package and encountered a minor issue. I need to match a string that can contain some special characters (.[{()\*+?|^$) as well. My question is if there is a way to tell Regex to treat this string "as is", including the special characters? I need to do this without escaping the special characters in the string or the match expression. For those of you familiar with Tcl Expect, I'm looking for an option similar to "expect -ex". Thank you! Regards, Dima Kagan

2 2

defining a function according to a signature given as template parameter
by Stefan Funck 09 Oct '07

09 Oct '07

Hi everybody, I'd like to have a generic wrapper that can be put "in between" a signal and a slot to provide some additional functionality to the slot. So where I normally have something like void myslot(int i) { std::cout << "slot(" << i << ")\n"; } int main(int argc, char *argv[]) { boost::signal<void (int)> sig; sig.connect(boost::bind(myslot, _1)); sig(123); return 0; } I want something like int main(int argc, char *argv[]) { boost::signal<void (int)> sig; SlotWrapper<void (int)> slotWrap(boost::bind(myslot, _1)); sig.connect(boost::bind(SlotWrapper<void (int)>::slot, &slotWrap, _1)); sig(123); return 0; } The signature of SlotWrapper<Signature>'s member function slot() is defined by Signature. slot()'s implementation should have some common functionality (that's what I want the wrapper for) and then call the actual slot that was given at construction (myslot() in the example above). Is that doable? So far I have two questions: 1) How can I define a member function according to the signature that is given as a template parameter to the class? 2) If I can do 1), how can I then bind the arguments given and call another function, i.e. the original slot? A skeleton of the wrapper might look like: template <typename Signature> class SlotWrapper { public: SlotWrapper(const typename boost::signal<Signature>::slot_function_type& slot) : m_slot(slot) {} // define a function according to Signature typename boost::signal<Signature>::result_type slot(...arguments...) { // do something common // call somehow the actual slot (m_slot) with the given ...arguments... } private: const typename boost::function<Signature> m_slot; }; How can I write the slot() function? Thanks for any help, Stefan

2 2

boost::basic_match::size_type
by Bill Webster 09 Oct '07

09 Oct '07

The basic_match access methods have int index parameters, whereas basic_match::size() returns basic_match::size_type. This means that the following results in compiler warnings (under MSVC 8.0) - boost::smatch match; // ... for ( boost::smatch::size_type i = 0; i < match.size(); i++ ) { cout << match.str( i ).c_str() << endl; }

1 0

Dimensional analysis
by Joel C. Salomon 09 Oct '07

09 Oct '07

Have the dimensional analysis templates suggested in <http://www.boost.org/libs/mpl/doc/tutorial/dimensional-analysis.html> ever been developed into readily usable form? --Joel

3 3

serialization and object tracking question...
by Graham Reitz 09 Oct '07

09 Oct '07

I am having trouble wrapping my head around object tracking for serialization. I see how to change the default behavior: BOOST_CLASS_TRACKING(my_class, boost::serialization::track_never) ...but based on the error below how do I determine what kind of object tracking is needed? oserializer.hpp:566: error: invalid application of 'sizeof' to incomplete type 'boost::STATIC_ASSERTION_FAILURE<false>' inline void save(Archive & ar, T &t){ // if your program traps here, it indicates taht your doing one of the following: // a) serializing an object of a type marked "track_never" through a pointer. // b) saving an non-const object of a type not markd "track_never) // Either of these conditions may be an indicator of an error usage of the // serialization library and should be double checked. See documentation on // object tracking. BOOST_STATIC_ASSERT(check_tracking<T>::value); The following is the class to be serialized: class client_i { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & m_client; } clients m_client; public: client_i() {}; client_i(clients c) : m_client(c) {}; ~client_i() {}; }; clients is a mysql++ specialized sql structure that is created via one of the mysql++ macros, i.e. sql_create_N(). Any help understanding this would be greatly appreciated. Thanks, Graham

2 4

thread creating just hangs
by Eyon Land 08 Oct '07

08 Oct '07

Hey folks, I'm new to boost. I've used pthread and wanted to try out boost::thread. After installing the latest release I found that creation of the thread instance simply hangs. I use CentOS 4.3 on a single CPU machine. Has this happened to anyone else? Thanks in advance! Eyon ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/

1 0