- Boost - lists.boost.org

[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