April 2010 - Boost - lists.preview.boost.org

[containers] flat_multimap compile errorin trunk
by Thorsten Ottosen 22 Apr '10

22 Apr '10

Hi Ion, The following code is making the compiler (vc9) choke: template<class D, class S> static D force_copy(S s) { value_type *vp = reinterpret_cast<value_type *>(&*s); return D(vp); } I don't get the code either? What is it good for, and why is a static_cast not good enough? If it helps, I'm using flat_multimap<BitSet,BitSet>, and not a build-in type. -Thorsten

3 4

[atomic] review schedule?
by Janek Kozicki 22 Apr '10

22 Apr '10

Hello, I recall that Atomic library was submitted for review, but I'm not seeing it in http://www.boost.org/community/review_schedule.html Why is that? When it will be reviewed? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

1 0

[Fusion] [Phoenix] VC10
by Richard Crossley 22 Apr '10

22 Apr '10

I'm trying to port an existing program from V9 to VC10. With both Boost head and the 1.43RC I get a lot of errors relating to Phoenix and Fusion, none of which I've been able to recreate with a simple test and the back trace of the error messages are somewhat confusing. However if I the change the two BOOST_WORKAROUND(BOOST_MSVC, <= 1500) to 1600 in /boost/fusion/container/vector/vector.hpp all the problems seem to go away. Perhaps someone who is more knowledge about this could take a look? Thanks, Richard. 4>c:\boost_1_43_0_beta1\boost/fusion/container/vector/detail/vector_n.hpp(68 ): error C2665: 'boost::fusion::vector_data2<Derived,T0,T1>::vector_data2' : none of the 3 overloads could convert all the argument types 4> with 4> [ 4> Derived=boost::fusion::vector2<boost::phoenix::argument<0>,boost::phoenix::v alue<bool (__cdecl property_t::* )(void) const>>, 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/detail/vector_n.hpp(45): could be 'boost::fusion::vector_data2<Derived,T0,T1>::vector_data2(const boost::phoenix::argument<N> &,const boost::phoenix::value<T> &)' 4> with 4> [ 4> Derived=boost::fusion::vector2<boost::phoenix::argument<0>,boost::phoenix::v alue<bool (__cdecl property_t::* )(void) const>>, 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> N=0, 4> T=bool (__cdecl property_t::* )(void) const 4> ] 4> while trying to match the argument list '(const boost::phoenix::composite<EvalPolicy,EvalTuple>, const boost::mpl::void_)' 4> with 4> [ 4> EvalPolicy=boost::phoenix::mem_fun_ptr_eval, 4> EvalTuple=boost::fusion::vector<boost::phoenix::argument<0>,boost::phoenix:: value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/detail/vector_n.hpp(105) : see reference to function template instantiation 'boost::fusion::vector_data2<Derived,T0,T1> boost::fusion::vector_data2<Derived,T0,T1>::init_from_sequence<Sequence>(con st Sequence &)' being compiled 4> with 4> [ 4> Derived=boost::fusion::vector2<boost::phoenix::argument<0>,boost::phoenix::v alue<bool (__cdecl property_t::* )(void) const>>, 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> Sequence=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/vector.hpp(58) : see reference to function template instantiation 'boost::fusion::vector2<T0,T1>::vector2<Sequence>(const Sequence &)' being compiled 4> with 4> [ 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> Sequence=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> c:\boost_1_43_0_beta1\boost/spirit/home/phoenix/core/composite.hpp(71) : see reference to function template instantiation 'boost::fusion::vector<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::vector<const U0>(const Sequence &)' being compiled 4> with 4> [ 4> T0=boost::phoenix::argument<0>, 4> T1=boost::phoenix::value<bool (__cdecl property_t::* )(void) const>, 4> T2=boost::fusion::void_, 4> T3=boost::fusion::void_, 4> T4=boost::fusion::void_, 4> T5=boost::fusion::void_, 4> T6=boost::fusion::void_, 4> T7=boost::fusion::void_, 4> T8=boost::fusion::void_, 4> T9=boost::fusion::void_, 4> U0=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, 4> Sequence=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> c:\boost_1_43_0_beta1\boost/fusion/container/vector/vector.hpp(58) : see reference to function template instantiation 'boost::phoenix::composite<EvalPolicy,EvalTuple>::composite<const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>>>(U0 &)' being compiled 4> with 4> [ 4> EvalPolicy=boost::phoenix::mem_fun_ptr_eval, 4> EvalTuple=boost::fusion::vector<boost::phoenix::argument<0>,boost::phoenix:: value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>, 4> T0=boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusion: :vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>, 4> T1=boost::fusion::void_, 4> T2=boost::fusion::void_, 4> T3=boost::fusion::void_, 4> T4=boost::fusion::void_, 4> T5=boost::fusion::void_, 4> T6=boost::fusion::void_, 4> T7=boost::fusion::void_, 4> T8=boost::fusion::void_, 4> T9=boost::fusion::void_, 4> U0=const boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::fusion::ve ctor<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusio n::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ] 4> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xlocnum(1081) : see reference to function template instantiation 'boost::fusion::vector<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::vector<boost::phoenix ::composite<EvalPolicy,EvalTuple>>(const Sequence &)' being compiled 4> with 4> [ 4> T0=boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boost::fusion: :vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>, 4> T1=boost::fusion::void_, 4> T2=boost::fusion::void_, 4> T3=boost::fusion::void_, 4> T4=boost::fusion::void_, 4> T5=boost::fusion::void_, 4> T6=boost::fusion::void_, 4> T7=boost::fusion::void_, 4> T8=boost::fusion::void_, 4> T9=boost::fusion::void_, 4> EvalPolicy=boost::phoenix::logical_not_eval, 4> EvalTuple=boost::fusion::vector<boost::phoenix::composite<boost::phoenix::me m_fun_ptr_eval,boost::fusion::vector<boost::phoenix::argument<0>,boost::phoe nix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, 4> Sequence=boost::phoenix::composite<boost::phoenix::logical_not_eval,boost::f usion::vector<boost::phoenix::composite<boost::phoenix::mem_fun_ptr_eval,boo st::fusion::vector<boost::phoenix::argument<0>,boost::phoenix::value<bool (__cdecl property_t::* )(void) const>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost: :fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void _,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fu sion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,b oost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> 4> ]

2 3

[interprocess][move] enum template argument fails to be a valid base class
by vicente.botet 22 Apr '10

22 Apr '10

I have find a possible bug on the move emulation on " Boost::Container::Vector with Enum Template Argument - Not Legal Base Class" http://stackoverflow.com/questions/2678476/boostcontainervector-with-enum-t… As rv inherits from the movable class template <class T> class rv : public T { rv(); ~rv(); rv(rv const&); void operator=(rv const&); }; it doesn't works for enum types. With gcc 3.4. I get ../../../boost/interprocess/detail/move.hpp:79: error: base type `Test::Types' fails to be a struct or class type. I don't know if this is a know issue with the move emulation. I have tried to add a specialization for is_movable namespace boost { namespace interprocess { // get inside boost template<> class is_movable<Test::Types> // add custom specialization of is_movable : public mpl::bool_<false> {}; }} but this doesn't works neither. I have tried to specialize the rv template with template <> class rv<Test::Types> { Test::Types v; rv(); ~rv(); rv(rv const&); void operator=(rv const&); operator Test::Types() const {return v;} }; and it compiles but the execution fails. Is there any workaround to this issue or better yet a generic solution? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 3

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 21 Apr '10

21 Apr '10

On Mon, Apr 19, 2010 at 1:04 PM, Thomas Jordan <thomasjordan_at_[hidden]> wrote: > Thomas Jordan wrote: >> [snip] >> I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just >> Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > ----------------------------------------- > Roland Bock replied: > > ************************************ > > <snip> > Â for_each(vov.begin(), vov.end(), > Â Â Â Â bind(for_each< vocType::iterator, function<void (myClass&)> >, > Â Â Â Â Â Â bind<vocType::iterator>(&vocType::begin, _1), > Â Â Â Â Â Â bind<vocType::iterator>(&vocType::end, _1), > Â Â Â Â Â Â protect(bind(&myClass::func, _1)) > Â Â Â Â Â Â ) > Â Â Â Â ); > } > // ----------------------------------------------------------- OvermindDL1 responded: You should use Boost.Phoenix, it can do what Bind and Lambda and others can, plus more, including the above with no issues. _____________________________________ Thanks for the suggestion. I will take a look at Phoenix. I have been drawn to Boost::bind because it is small, self-contained, relatively easy to understand and surprise-free. I like the extra power of Lambda - it is beautiful for relatively simple operator expressions and function bindings, however, when I tried to do anything more complex, e.g., multiple Lambda sub-expressions separated by commas, it started to go wrong for me. I found it difficult to predict what would happen, esp. with regard argument binding, order of evaluation, side-effects, etc. Even when I saw the result, I wasn't sure how it had got there. This could just be due to my lack of experience, holes in the documentation, or even compiler issue. Also, the syntax what is bit prickly. I am not trying to start a 'which is best Boost functional library' thread, but such issues, if present, would (sadly) steer me away from Phoenix too. I just couldn't recommend it to your average C++ programmer at my workplace. Also, I got the impression Boost::bind is in TR1, therefore is likely to be in the next standard, whereas Lambda expressions would be best handled by core-language extensions (also mooted for the standard)? Finally, if Boost::Phoenix is so good (I don't doubt it that it is), why is is buried away under another library, and are there any plans to consolidate/deprecate any/all of these libraries? Best regards, Tom.

2 2

[GGL] [geometry] Inexplicable speed benefit when using Visual C++ 2010
by Christian Buchner 21 Apr '10

21 Apr '10

Hi everybody, my first attempt to post to this list bounced, so I am trying again. My employer is an early adopter of the Boost Generic Geometry Library [GGL] in an engineering application related to mobile radio communicatons. We use it to estimate and optimize the coverage of 4G radio networks. Our code uses a lot of multi-polygon unions to estimate the amount of ground covered (and not covered) by radio beams and iteratively improves the antenna parameters. We've been compiling and shipping our application with Visual C++ 2008 so far. We found that GCC 4.4 on Linux was about 100% faster than Visual C++ 2008 on Linux without modifying the code. This bothered us quite a bit as both compilers were allowed to use full optimization. We found that by optimizing (globaly overloading) the new and delete operators to re-use allocated memory fragments on Windows we were able to get nearly 50% speed benefit, so we attributed much of the performance difference to sub-optimal memory heap management of Visual C++ 2008. Then we tried recompiling the project with Visual C++ 2010 Ultimate Release Candidate (RC). The speed gain of the algorithm was 900% (not joking) and the results still appear to be correct. Now this is surreal and no one here in the office has found a reasonable explanation yet without going into the metaphysical domain. Would anyone with knowledge of compiler and runtime internals be able to make an educated guess as to how such a speed gain of factor 10 is possible? Is anyone else seeing similar speedups in boost or in the geometry library when compiling with Visual C++ 2010 RC (HINT: it's a free download, so anyone can try it out until end of June 2010). Christian

10 13

[circular_buffer] Patch to fix two-phase name lookup issue in space_optimized
by Doug Gregor 21 Apr '10

21 Apr '10

Hello Boosters, In the space_optimized circular buffer, the two calls to invalidate_iterators_except require a preceding "this->". The actual invalid_iterators_except() function is only accessible through a dependent base, so we need to make the invalid_iterators_except name dependent. The DEC compiler tried to tell us this at one point, but we ignored it. Patch is attached. - Doug

3 3

Volunteering to fix inspection issues
by Jeremiah Willcock 21 Apr '10

21 Apr '10

I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)? -- Jeremiah Willcock

4 7

Re: [boost] [utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Christophe Henry 21 Apr '10

21 Apr '10

> Eric Niebler wrote: > >> I suspect the real problem is in a buggy implementation of decltype on >> msvc-10. For the upcoming boost release, I suggest that we stick with >> the non-decltype implementation of result_of on msvc-10, or risk >> massively breaking users' code, not to mention proto, spirit and >> xpressive on that compiler. > > MSVC10 isn't even released yet. > Why bother with a non-stable compiler? > I start having a bit of experience with decltype and VC compilers (sigh) through my eUML front-end for MSM and I can give you one reason: because it's probably not just VC10. I have here and there this problem (and others) with VC9 too. It might just happen in different conditions. Christophe

13 65

[move] Reason for BOOST_COPY_ASSIGN_REF?
by Chad Nelson 21 Apr '10

21 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been studying Boost.Move, with an eye toward using it to incorporate move semantics into the XInt library. Most of it looks pretty straightforward, but I don't understand the reason for the BOOST_COPY_ASSIGN_REF macro. If you already have a copy-constructor that takes a reference, what does it give you? Also, how close is it to being official? I'd like to use it, but if it's not going to be accepted any time soon, I can't justify it. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvOY7AACgkQp9x9jeZ9/wRK1gCgvukakBrO37sCmHKwdhf9ebsI rt8AmwYk3WwDZkUiUKKXb76Jeuh3n3w4 =8EHR -----END PGP SIGNATURE-----

4 8

[containers] flat_set/flat_map could add insert_sorted(begin, end)
by Thorsten Ottosen 21 Apr '10

21 Apr '10

Hi Ion, I think the above member could be useful (taking an already sorted sequence), especially if the container needs to reallocate, in which case we may merge the two sequences [begin,end) [lower_bound(*begin),upper_bound(*(end-1))] and copy the unaltered prefix and suffix. Furthermore, even when we don't have to reallocate, we can bulk copy the suffix and simulate merging for the infix range. Any comments? -Thorsten

3 5

[filesystem] forward declaration headers
by Alexander Arhipenko 21 Apr '10

21 Apr '10

Hi boosters, I think it would be nice for boost filesystem to maintain forward declarations headers, e.g. <boost/filesystem/fwd.hpp>. Regards

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 21 Apr '10

21 Apr '10

Thomas Jordan wrote: > Hi, > I have been trying to use Boost.bind to create an 'STL algorithm function object' to pass into another, 'higher order,' STL algorithm (e.g., to pass a for_each into a for_each). However, I am struggling to get bind to deduce the correct return type of the for_each function object. I include the relevant bits of the code below. > > class myClass > { > public: > int func(){return mValue;} > private: > int mValue; > }; > > //wrapper for STL for_each > struct myForEach > { > template <typename II, typename F> > F operator()(II begin, II end, F function) const > { > return std::for_each(begin, end, function); > } > }; > > typedef vector<myClass> vocType; > typedef vector<vocType> vovType; > > //overloaded member functions vocType::begin & end > typedef vocType::iterator (vocType::*fnPtr)(); > typedef const vocType::iterator (vocType::*constFnPtr)() const; > > vovType vov(10, vocType(10, myClass())); > > main() > { > for_each(vov.begin(), vov.end(), > bind< ? >(myForEach(), > bind(static_cast<fnPtr>(&vocType::begin),_1), > bind(static_cast<fnPtr>(&vocType::end),_1), > protect(bind(&myClass::func, _1))) > } > > I tried various things for bind<?>, but was only able to get the code to compile (eventually) on my Unix box when I substituted > bind< boost::_bi::protected_bind_t<boost::_bi::bind_t<int, boost::_mfi::mf0<int, myClass>, boost::_bi::list1<boost::arg<1> (*)()> > > > for > the bind<?>. I had guessed this might work from studying the compiler error messages. Obviously, this is not an ideal solution! > > Also, I only used the myForEach wrapper after having first attempted - and similarly failed - to bind the raw STL for_each. > > Is there any way I can help bind to deduce the correct return type - for either myForEach or std::for_each, or both? > > > --Roland Bock wrote------------------------------------------------------------------ In my experience it is easier to use a named functor object. Such as function<void (const vocType&)> functor = bind(&myClass::func, _1); std::for_each(vov.begin(), vov.end(), functor); Untested, but I am pretty sure something along these lines will work. Regards, Roland ------------------------------------------------------------------------------------------------- Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible?

5 9

[serialization] alternative with inter-thread and network messaging
by Scott Woods 21 Apr '10

21 Apr '10

Hi Boost, I've been developing a serialization library to prove a few concepts and this has recently started to bear fruit. It tackles the problem space in quite a distinct way resulting in features like runtime-selectable encodings and out-of-the-box network messaging. Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web Aspects of the design came from sources such as; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf<http://www.cs.wustl.edu/%7Eschmidt/PDF/Act-Obj.pdf> ) The work was motivated by years of battling with proprietary encodings, configuration files, data formats, telephony signaling systems and TCP application protocols. This is a framework to give all the related pieces a proper place and more importantly, to keep things like network APIs out of application code. I would be interested in submitting this for Boost review but suspect that the library is too big. It also overlaps with a long list of existing components including serialization, asio, MPI, threads, uuid, any, variant and statechart. Maybe the integration of all those facilities is interesting to Boost? Or if there was something that could be carved off for separate submission - perhaps the UTF templates? Advice from moderators would be appreciated. Cheers, Scott

1 0

[serialization] alternative with inter-thread and network messaging
by Scott Woods 21 Apr '10

21 Apr '10

Hi Boost, I've been developing a serialization library to prove a few concepts and this has recently started to bear fruit. It tackles the problem space in quite a distinct way resulting in features like runtime-selectable encodings and out-of-the-box network messaging. Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web Aspects of the design came from sources such as; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf) The work was motivated by years of battling with proprietary encodings, configuration files, data formats, telephony signaling systems and TCP application protocols. This is a framework to give all the related pieces a proper place and more importantly, to keep things like network APIs out of application code. I would be interested in submitting this for Boost review but suspect that the library is too big. It also overlaps with a long list of existing components including serialization, asio, MPI, threads, uuid, any, variant and statechart. Maybe the integration of all those facilities is interesting to Boost? Or if there was something that could be carved off for separate submission - perhaps the UTF templates? Cheers, Scott

1 0

[range] Request to merge minor small defect fixes
by Neil Groves 20 Apr '10

20 Apr '10

Please may I merge some very small defect fixes for Boost.Range, and an additional test? The defect fixes are to improve return types consistency. I would like to get the interface correct for the first release of the merged RangeEx code. I have also added a test case that checks the use of non-member functions as functors and explicitly tests chaining of Range Adaptors. I believe this provides appreciably better visibility of the state of the library on the various compilers. These changes have been passing tests on the trunk for several days. The changes are also extremely low impact as they are in the new Range code that is not yet used within the rest of the Boost libraries. Thanks, Neil Groves

3 5

Bug #2501: upgrade_to_unique_lock doesn't compile on C++0x mode
by Rodolfo Schulz de Lima 20 Apr '10

20 Apr '10

Hi, is there any chance that the patch attached to bug #2501 can/will be in 1.43? It works for me (with minor patch adjustments) and IMHO is safe to be merged into trunk. I've been patching my local copy of boost for the last 6 releases... I'm a little tired of doing that :) []s, rod

3 4

[release] Permission to merge fix for issue 2501 in boost.thread
by Anthony Williams 20 Apr '10

20 Apr '10

Hi, I just committed a fix for issue 2501 to trunk. Can I merge this to release once the tests have cycled? Thanks, Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 2

[GSoC] Requesting a review on my GSoC proposal
by Stefan 20 Apr '10

20 Apr '10

Hello. I apologize for being so persevering but I have posted a comment on my proposal and received no feedback yet. It would be greatly appreciated if you could let me know of your opinion in connection to my application as well as request any clarification if applicable. Proposal link: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/ms… (private, thus viewable only by mentors) Best wishes, Stefan

1 0

[mpl] aux_::template_arity subtly broken on gcc-4.5
by Eric Niebler 20 Apr '10

20 Apr '10

First, I freely acknowledge that I have been relying on an implementation detail of MPL, and I will spend an appropriate amount of time doing penance in programmer purgatory after I die. That said ... Xpressive is broken on gcc-4.5 because mpl::aux_::template_arity is causing instantiations on that compiler that it shouldn't. Consider the following program that compiles on gcc-4.4 but not gcc-4.5. #include <boost/mpl/aux_/template_arity.hpp> #include <boost/mpl/aux_/lambda_arity_param.hpp> template<class A> struct T : A::x {}; template< class T BOOST_MPL_AUX_LAMBDA_ARITY_PARAM( int Arity = boost::mpl::aux::template_arity<T>::value ) > struct S {}; template<template<class A> class P, class X> struct S<P<X> BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(1)> {}; int main() { S<T<int> > s0; } The error I get is: bug4109.cpp: In instantiation of ‘T<int>’: ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:85:5: instantiated from ‘const int boost::mpl::aux::template_arity_impl<T<int>, 1>::value’ ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:93:5: instantiated from ‘const int boost::mpl::aux::template_arity<T<int> >::value’ ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98:30: instantiated from ‘boost::mpl::aux::template_arity<T<int> >’ bug4109.cpp:23:14: instantiated from here bug4109.cpp:6:3: error: ‘int’ is not a class, struct, or union type Any chance of a fix? -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 3

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 20 Apr '10

20 Apr '10

Thomas Jordan wrote: > [snip] > Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > Roland Bock replied: ************************************ Hi Thomas, we don't say it isn't possible :-) Here you go: // ----------------------------------------------------------- #include <boost/bind.hpp> #include <boost/bind/protect.hpp> #include <boost/function.hpp> #include <vector> #include <iostream> using namespace std; using namespace boost; int initValue = 0; class myClass { public: myClass(): mValue(initValue) {} myClass(const myClass& rhs): mValue(initValue++) { } void func() { cout << mValue << endl; } private: int mValue; }; typedef vector<myClass> vocType; typedef vector<vocType> vovType; int main() { vovType vov(10, vocType(10, myClass())); for_each(vov.begin(), vov.end(), bind(for_each< vocType::iterator, function<void (myClass&)> >, bind<vocType::iterator>(&vocType::begin, _1), bind<vocType::iterator>(&vocType::end, _1), protect(bind(&myClass::func, _1)) ) ); } // ----------------------------------------------------------- Please let me know if this is working for you. Regards, Roland ************************************************************** Thanks a lot, Roland, this looks good. I felt there must be some way to do it, but it was just beyond my grasp. Always learning! Regards, Tom.

2 1

[config] Compiler defects value-initialization
by Niels Dekker - address until 2010-10-10 19 Apr '10

19 Apr '10

The Config/trunk regression page currently shows some detailed information of various compiler defects regarding value-initialization: http://www.boost.org/development/tests/trunk/developer/config_.html If anyone wants to have a look at these results, please do so quickly! The output is from boost_no_complete_value_initialization::test(), which tests whether a specific compiler should have a new defect macro defined, BOOST_NO_COMPLETE_VALUE_INITIALIZATION. In a few days, I'm planning to add this definition to the Boost Config files of those compilers [Boost #4080], and then the test output will disappear automatically. According to the current test results, two compilers do an excellent job w.r.t. value-initialization: Intel (10.1, 11.0, 11.1) on Mac OS X, and GCC 4.4.3 (both on Linux and Windows). Compilers that don't completely do value-initialization include Microsoft Visual C++ (including msvc-10.0), Borland (including CodeGear 2010), Sun 5.10, and IBM XL V10.1. The MSVC defect was reported back in 2005 [Visual Studio #100744]. I recently reported the value-initialization defects I encountered on Embarcadero CodeGear [Embarcadero #83751, #83851] and IBM XL. The Windows version of Intel 11.1 doesn't do so well either, according to results from Huang-Vista-x86_32_intel. I still wonder why, because on Mac OS X, Intel does so well. GCC also has regression failures w.r.t. value-initialization, but those are only on earlier GCC versions, like gcc-4.2.4 and gcc-4.3.4. The last GCC bug in this area, AFAIK, [GCC #30111] was fixed for GCC 4.4. As far as I have seen, any compiler supports value-initialization of integers, floating point numbers and pointers correctly. However, problems occur for structs, classes, and arrays. Objects of those types may be left partially or entirely uninitialized, when they should have been value-initialized, depending on the compiler. I hope to have the test and the defect macro included with Boost 1.44. Please let me know if you have any comment or question about them. https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_com_value_i… Kind regards, Niels References: [Boost #4080] "Various compilers need BOOST_NO_COMPLETE_VALUE_INITIALIZATION", https://svn.boost.org/trac/boost/ticket/4080 [Visual Studio #100744] "Value-initialization in new-expression", reported by Pavel Kuznetsov: https://connect.microsoft.com/VisualStudio/feedback/details/100744 [Embarcadero #83751, #83851] Two value-initialization bugs I recently reported: http://qc.embarcadero.com/wc/qcmain.aspx?d=83751 http://qc.embarcadero.com/wc/qcmain.aspx?d=83851 [GCC #30111] "Value-initialization of POD base class doesn't initialize members", reported by Jason Merrill: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111 -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type offor_each?
by Thomas Jordan 19 Apr '10

19 Apr '10

Thomas Jordan wrote: > Thanks a lot for the suggestion, I did take a look at Lambda library, and > I saw that it used some extra type information in its STL > algorithm wrappers (the 'sig') to help it figure out the return types. > However, I am against using the Lambda library > for other reasons, I only want to use the bind library. I'd appreciate > some specific advice on how to get the type deduction > with the Boost.bind library. Or is this just not possible with > Boost.bind? Peter Dimov replied: ----------------- It's not. Boost.Bind only supports function objects with a specific, fixed type. There is no mechanism to tell it that the return type of struct myForEach { template <typename II, typename F> F operator()(II begin, II end, F function) const { return std::for_each(begin, end, function); } }; is the same as its third argument. In this specific case I'd just use struct myForEach { typedef void result_type; template <typename II, typename F> void operator()(II begin, II end, F function) const { std::for_each(begin, end, function); } }; -------------------- Thanks, Peter, and thanks to everyone else who replied, for their helpful suggestions. FWIW, I'm putting together a presentation for my colleagues, to show the facilities for higher-order programming in STL and Boost, and I wanted to show a couple of 'out-there' examples to illustrate their power. I'm a bit of an arriviste and my C++ is 'improving,' but I'm really impressed that you can do functional-style programming so nicely in C++. Regards, Tom.

2 1

libzeep
by Maarten L. Hekkelman 19 Apr '10

19 Apr '10

As I announced earlier, I've released a library that can be used to create SOAP servers. Since this code relies heavily on XML, I've implemented a full XML parser and XPath implementation as well. I've read a bit in the discussion on this forum regarding the implementation of XML parsers and I get the feeling some don't fully appreciate the amount of work that goes into writing a validating parser. There really is more to XML than the characters < and >. :-) If there's a DOCTYPE, the results of parsing a file can be surprising since the DTD can e.g. specify default attribute values. To test libzeep I'm using the 1808 test files provided by the w3c organisation. Of these I only test against 1490 since the others only check unicode characters that are allowed since XML version 1.1. Of the remaining 1490 only 14 produce dubious output, I'm not really sure if these tests are wrong or that my code is incorrect. Anyway, libzeep performs quite nicely. The code has not yet been profiled but I've been able to replace libxml2 in all my projects and see hardly any performance degradation and my code looks much better now. All in all, I think libzeep is quite feature complete, robust and performs nicely. I've released the code and minimal documentation at http://www.cmbi.ru.nl/libzeep Now suppose people here are interested in this library, I'm willing to spend some time to upgrade the code to boost quality standards and write more documentation. And if the boost community prefers another approach I'm willing to provide help based on my recent experience. I'm looking forward to your feedback. -maarten

9 15

[exception] [shared_ptr] ADL problem with msvc 10
by Steven Watanabe 19 Apr '10

19 Apr '10

AMDG I just tried to compile the following #include <boost/exception_ptr.hpp> void f() {} msvc 10 complains, 1>c:\boost\trunk\boost\smart_ptr\detail\sp_convertible.hpp(48): error C2660: 'f' : function does not take 1 arguments 1> c:\boost\trunk\boost\smart_ptr\detail\sp_convertible.hpp(66) : see reference to class template instantiation 'boost::detail::sp_convertible<Y,T>' being compiled 1> with 1> [ 1> Y=error_info_tag_t, 1> T=boost::exception_detail::error_info_base 1> ] 1> c:\boost\trunk\boost\exception\info.hpp(171) : see reference to class template instantiation 'boost::detail::sp_enable_if_convertible<Y,T>' being compiled 1> with 1> [ 1> Y=error_info_tag_t, 1> T=boost::exception_detail::error_info_base 1> ] 1> c:\boost\trunk\boost\exception\info.hpp(188) : see reference to function template instantiation 'const E &boost::exception_detail::set_info<E,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 1> with 1> [ 1> E=boost::unknown_exception, 1> Tag=boost::tag_original_exception_type, 1> T=const type_info * 1> ] 1> c:\boost\trunk\boost\exception\detail\exception_ptr.hpp(132) : see reference to function template instantiation 'const boost::unknown_exception &boost::operator <<<boost::unknown_exception,boost::tag_original_exception_type,const type_info*>(const E &,const boost::error_info<Tag,T> &)' being compiled 1> with 1> [ 1> E=boost::unknown_exception, 1> Tag=boost::tag_original_exception_type, 1> T=const type_info * 1> ] 1> c:\boost\trunk\boost\exception\detail\exception_ptr.hpp(111) : see reference to function template instantiation 'void boost::unknown_exception::add_original_type<std::exception>(const E &)' being compiled 1> with 1> [ 1> E=std::exception 1> ] This appears to be because type_info is defined in the global namespace, so ADL for boost::error_info<boost::tag_original_exception_type, const type_info *> picks up the global f. I don't have a fix for this yet. In Christ, Steven Watanabe

3 5