- Boost - lists.preview.boost.org

[geometry] few questions
by Janek Kozicki 23 Apr '10

23 Apr '10

Hello, By looking at the documentation I can see that Geometry library is great for 2D polygons. I am working in 3D, so I wanted to ask about what I can, and what I can't. Is it possible to define 3D shapes, calculate their intersections, unions and so on? What about centroids and second (geometrical) moments of inertia? Does the geometry deal with spheres, or maybe other classical 3D geometries, like ellipsoid, torus or cone? What about the infinite geometries (like infinite cone)? Or infinitely long line? Also I wanted to ask about 3D points regarded as vectors. Can I add and subtract them? What about 3D vector cross product. What about dot product? I guess that I need to write that 'very old formula' function myself? In fact, since you are well into the subject, perhaps you could tell me if there are anywhere in boost a vector dot product and cross product implemented? Last but not least - I am doing frequently a 3D rotation of 3D points using quaternions for that (this could work with rotation matrices too). I suppose that I would need to implement this myself to "link" boost::quaternion with boost::geometry::point3d. please enlighten me and thank you very much for your time -- Janek Kozicki http://janek.kozicki.pl/ |

3 4

BOOST_EXPLICIT_OPERATOR_BOOL macro?
by Christian Holmquist 23 Apr '10

23 Apr '10

Hi, IIUC, c+0x allows the safe bool idiom to be implemented as explicit operator bool() const { ...} but in c+03 emulating that behaviour is a bit messy. There appears to be a solution for c+03 in boost/smart_ptr/detail/operator_bool.hpp, but it's targeted for the smart_ptr classes only. Would it be possible to extract operator_bool.hpp into a reusable macro, something like: #include <boost/utility/operator_bool.hpp> struct some { BOOST_EXPLICIT_OPERATOR_BOOL( m_value != 0; ) int m_value; }; What do you think? Cheers, Christian

3 5

[range] new adaptor for iterating over equal_ranges
by Thorsten Ottosen 23 Apr '10

23 Apr '10

Hi Neil & others, I think it could be useful with a range adaptor of the following kind to iterate over equal_ranges in a multimap. E.g. SomeMultiMap map = ...; for( auto rng : map | boost::adaptors::equal_ranged ) for( auto iter : rng ) { // do something with the objects with equal keys } The resulting range would probably be bidirectional with value_type std::pair<boost::range_iterator<SomeMultiMap>::type,...>. Thoughts? -Thorsten

2 1

Fwd: Re: [interprocess][move] enum template argument fails to be a valid base class
by Ion Gaztañaga 23 Apr '10

23 Apr '10

>i think I spoke too fast, is_enum needs compiler intrinsics according >to >boost documentation, so maybe this approach is not very useful... Forget it. I was talking about is_union instead. God, the lack of coffee is killing me ;-) Best, Ion

2 4

[1.43.0] Beta 1 Release Candidates available
by Beman Dawes 23 Apr '10

23 Apr '10

The 1.43.0 Beta 1 Release Candidate files are available at http://boost.cowic.de/rc/ Before these get pushed out to SourceForge, we like to get verification that they download and build OK on at least Linux and Windows. So please download one of these for your favorite platform, try a build, and report success or failure here. Thanks, --Beman

5 9

[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