- Boost-users - lists.boost.org

[serialization]-- boost integrated with MFC Doc/View?
by Rich Peters 13 Oct '07

13 Oct '07

I am looking at boost serialization and it looks very good. Has anyone tried to integrate boost serialization with MFC Doc/View CArchive serialization? I would be interested to hear how you did it. Can a CArchive be turned into a istream or ostream that could be used? thanks

2 1

ptr_set problems
by Surya Kiran Gullapalli 13 Oct '07

13 Oct '07

Hello, I'm using ptr_set for one of my classes whose structure is like this. =============================== using namespace boost; class A: less_than_comparable<A>, equality_comparable<B>, noncopyable { friend operator< (const A&, const A&) ; public: A() virtual ~A () virtual void fun1() = 0 ; } class B: public A { public: B () ; ~B () ; virtual void fun1() { cout << "Func1 in B" << endl ; } } class C : public A { public: C () ; ~C () ; virtual void fun1() { cout << "Func1 in C" << endl ; } } ============================================== and I'm inserting into ptr_set like this. A *varb = new B () ; A *varc = new C() ; ptr_set <A> Aset ; Aset.insert (varb) ; Aset.insert (varc) ; **************** Compilation is fine on windows (VS2005) and linux (gcc-4.1.2) On linux, the code executes fine. But on windows, I'm getting a DEBUG ASSERTION failure during insertion. The failure says, Expression: invalid operator<. This happens in debug version only. In release version, the code executes fine on windows also. Any help on how to attack this problem is greatly appreciated. Thanks in advance, Surya

2 1

Making an ordinary function into something useful in lambda expressions
by Peter Waller 13 Oct '07

13 Oct '07

I wish to write some lambda functions to have this sort of behaviour. #include <lambda/lambda.hpp> #include <lambda/bind.hpp> #include <function.hpp> using namespace boost::lambda; using namespace boost; #include <iostream> using std::cout; using std::endl; #include <cmath> int main( int argc, char *argv[] ) { float value; var_type<float>::type theValue( var( value ) ); // Ignore this line #define cos(theta) bind( unlambda(bind( cos, _1 )), theta ) function<float ( float )> myfunction = ( cos( theValue ) - 1 ); value = 2; cout << "The result = " << myfunction(1) << endl; return 0; } Namely, the cos( value ) part. The code above works, but I feel that using a #define is a little messy, and seems hard to generalise to functions with more arguments. I was wondering if there was a general, better way of turning a given function into one whose execution is delayed. Thanks in advance, - Peter

3 3

[boost-users][function, assign] error C2986 and C2784 on visual studio 2005 .
by chun ping wang 13 Oct '07

13 Oct '07

So given this header. template < QSTYPE type, typename T, template <typename ELEM, typename = std::allocator<ELEM> > class CONT > CONT<T> quicksort(CONT<T>); // inside the main file. // I decided a function that takes vector of integer and returns a vector of integer. typedef boost::function<std::vector<int>(std::vector<int>)> sortfunc; // create a function list to hold the sorting function. // bunch of number include. #include <boost/assign/std/vector.hpp> std::vector<sortfunc> function_list; using boost::assign::operator+=; std::vector<sortfunc> function_list; // quicksort random function_list += (&algocpw::quicksort<algocpw::QSTYPE(algocpw::RANDOM), int, std::vector>), // quicksort median (&algocpw::quicksort<algocpw::QSTYPE(algocpw::MEDIAN), int, std::vector>), // quicksort mediantriple (&algocpw::quicksort<algocpw::QSTYPE(algocpw::MEDIANTRIPLE), int, std::vector>), // merge sort (&algocpw::mergesort<int, std::vector>), // heap sort (&algocpw::heapsort<int, std::vector>), // selection sort (&algocpw::selection_sort<int, std::vector>), // standard sort (&algocpw::standard_sort<int, std::vector>); I get the following errors. ./cs512/c++/sortingMain.cpp(63) : error C2896: 'boost::assign::list_inserter<boost::assign_detail::call_push_back<std::vector<_Ty,_Alloc>>,V> boost::assign::operator +=(std::vector<_Ty,_Alloc> &,V2)' : cannot use function template 'CONT<T> algocpw::mergesort(CONT<T>)' as a function argument c:\cpw\msvc\cs512\c++\def\../sortingAlgo.hpp(32) : see declaration of 'algocpw::mergesort' ./cs512/c++/sortingMain.cpp(63) : error C2784: 'boost::assign::list_inserter<boost::assign_detail::call_push_back<std::deque<T,Allocator>>,V> boost::assign::operator +=(std::deque<T,Allocator> &,V2)' : could not deduce template argument for 'std::deque<T,Allocator> &' from 'std::vector<_Ty>' with [ _Ty=sortfunc ] Where did "deque" come from.. i never included deque.

1 0

[ANN] Xpressive 2.0.0
by Eric Niebler 12 Oct '07

12 Oct '07

Xpressive has just reached 2.0! The new version has lots of cool new features (see below). Subversion and the File Vault both have the latest code. It works with HEAD and with Boost v1.34.1. Below is an earlier message announcing the feature set of xpressive 2.0. The latest docs are here: http://boost-sandbox.sourceforge.net/libs/xpressive/doc/html/index.html Also, xpressive.zip in the File Vault (Strings - Text Processing directory) contains the docs in pdf format. Please grab the latest code and let me know of any problems you encounter so I can get them fixed for 1.35. -- Eric Niebler Boost Consulting www.boost-consulting.com Eric Niebler wrote: > It's a poorly kept secret that I've been adding new features to > Xpressive on CVS HEAD for a while now. So here are the features already > implemented (documentation forthcoming) for Xpressive 2.0: > > << Semantic Actions >> > > Specify code to execute when parts of a regex match, a-la Spirit's > semantic actions. Eg.: if you want to parse a string of name/value pairs > into a std::map, you might: > > std::map<std::string, int> result; > std::string str("aaa=>1 bbb=>23 ccc=>456"); > > // Like "(\\w+)=>(\\d+)": > sregex pair = ( (s1= +_w) >> "=>" >> (s2= +_d) ) > [ ref(result)[s1] = as<int>(s2) ]; > sregex rx = pair >> *(+_s >> pair); > > if(regex_match(str, rx)) > { > assert(result["aaa"] == 1); > assert(result["bbb"] == 23); > assert(result["ccc"] == 456); > } > > The actions are placed on a queue and executed in order only when the > regex match succeeds. > > << Custom Assertions >> > > Use the check() function to create a boolean predicate that can > participate in the match. Here's a regex that recognizes two integers > only if the first is less than the second: > > sregex rx = ( (s1= +_d) >> ' ' >> (s2= +_d) ) > [ check( as<int>(s1) < as<int>(s2) ) ]; > > Unlike actions, predicates execute immediately. You can also define the > predicate out-of-line as a function object. > > << Dynamic Regex Grammars with Named Regexes >> > > Using regex_compiler, you can map a name to a regex object, and then > refer to that regex from another by name. In this way, you can build > grammars from regexes at runtime. > > sregex_compiler comp; > sregex rx = comp.compile("^bar(?$RE)baz$"); > comp.compile("(?$RE=)\\d+ \\d+"); > > There's an alternate syntax for associating a name with a regex that you > can use to nest a static regex in a dynamic one. Eg., the last line > above could be: > > comp["RE"] = +_d >> ' ' >> +_d; > > With these changes, you can now nest static and dynamic regexes within > each other freely, giving you lots of flexibility to build grammars and > modify them on the fly. > > << Named Captures >> > > For dynamic regular expressions, you can create a named capture with > (?P<name> ...). You can refer back to the named capture with (?P=name). > In substitution strings (for use with regex_replace()), you can refer > back to a named capture with \\g<name> when using the format_perl or > format_all flags. > > And more .... I'd like to give props to Dave Jenkins who has been doing > m4d things with this stuff already, and who has given me a laundry list > of other features he'd like.

1 0

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