October 2007 - 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