August 2009 - Boost - lists.preview.boost.org

[mirror] automatic reflection / boost.mirror still in development?
by strasser＠uni-bremen.de 23 Aug '09

23 Aug '09

is boost.mirror (sandbox: https://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/ ) still in development? looks a bit abandonded to me. when I first saw it I was not too excited about it because I don't think a reflection library that requires the user to register every c++ construct manually is very usable. but GCC recently (finally) integrated a plugin infrastructure, so it would be possible to automatically generate reflection information. I've worked with the GCC internal tree before, it's pretty close to the c++ constructs in the early stages. something like this would be possible: test.cpp: //include result of GCC plugin of test.cpp: #include "test.rpp" class myclass{ int myvar; double myfunction(); }; int main(){ typedef reflection::myclass::myvar::type ret; BOOST_STATIC_ASSERT(is_same<ret,int>::value); typedef reflecton::myclass::myfunction::type::return_type ret; BOOST_STATIC_ASSERT(is_same<ret,double>::value); } //or, lookup in MPL map: template<class T> char const *lookup_name(){ return reflection::type<T>::name; } or anything else you can do with MPL sequences, like iterating over class members. this would have some downsides though: - GCC the library user must install GCC. other compilers can still be used for compilation, but the code to be reflected must be portable to GCC. - license the code generating plugin must be GPLed. that does not affect the license of the user code or other parts of boost though. acceptable downsides imho, given that there are no practical alternatives in sight, like a standard conforming boost C++ parser. what do you think?

4 4

[Exception] Why is there no non-const version of get_error_info?
by Adam Badura 23 Aug '09

23 Aug '09

get_error_info takes a const exception object and returns a pointer to const data object of respective error_info. But why is there no way of getting non-const pointer (which would allow to modify the data)? This is especially strange because operator << can be used to add data to a const exception object so I don't see reason for not being able to get modifiable data back (at least from non-const exception object). Having this would allow me to safely gather exception data before throwing or during exception propagation. What I wanted was to insert an empty vector of data to the preconstructed exception object. Then obtain the vector with get_error_info (since operator << adds a copy I have to get the actual object). Then call reserve on the obtained vector and start the actual operation. During the operation I can gather (possible) error data and safely add it to the vector since memory is already reserved. In the end if any error data was gathered I will throw the preconstructed exception object. In reasonable implementation this should be safe as well. (Similar thing might be done while propagating the exception.) With current code (lack of non-const get_error_info) it is not possible. I have to get the vector from exception object. Then add data to the vector (this may fail). Then again add vector to the exception object (overwriting old vector; this may fail). And in the end throw (if needed). Alternatively I could preconstruct vector, reserve space add data to it. Then in the end if I will throw the data vector is there for me. However I still have to add it to the exception object and this still may fail. Adam Badura

4 15

[fusion] Minor interface change
by Joel de Guzman 23 Aug '09

23 Aug '09

Hi Y'all, Heads up. There will be a minor interface change. vector0 will now be a template: vector0<> to better reflect MPL. This also addresses Boost Trac ticket #1608: https://svn.boost.org/trac/boost/ticket/1608 Please adjust your code accordingly, or holler if you have any complaints. Unless there are objections, I'll commit the code as soon as all the relevant regression tests pass. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

2 3

request for help: g++ compiler error in mapreduce library
by Craig Henderson 22 Aug '09

22 Aug '09

Can someone please help me with a g++ compiler error with my MapReduce library test program? My primary development platform is MSVC 2005 on Windows. I have an Ubuntu box with g++ 4.3.3 which I am not particularly familiar with. Compiling the test program 'mrtest' in boost-sandbox/libs/mapreduce/test on g++, I get an error which I cannot resolve: mrtest.cpp:228: error: expected primary-expression before '>' token here's the piece of code (the full source is in https://svn.boost.org/svn/boost/sandbox/libs/mapreduce/test/mrtest.cpp) typename Job::datasource_type datasource(spec); Job job(datasource, spec); job.run<boost::mapreduce::schedule_policy::cpu_parallel<Job> >(result); // <-- ERROR The code compiles and runs fine on Windows. Any ideas? Thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

2 3

Subversion update and boost release schedule
by Marshall Clow 21 Aug '09

21 Aug '09

Begin forwarded message: > Date: Fri, 21 Aug 2009 17:00:19 -0400 > From: "Kim, DongInn" <dikim(a)osl.iu.edu> > To: all-osl-users(a)osl.iu.edu > Subject: [all-osl-users] Upgrading of the OSL SVN server and trac > Sender: osl-mailman-bounces(a)wowbagger.osl.iu.edu > > Hi, > > The new version(1.6.3) of subversion was released on June 2009. It > has a lot of good features included and many bugs are fixed. > http://subversion.tigris.org/servlets/ProjectNewsList > > The OSL would like to upgrade the current subversion(ver 1.5.5) to > get the benefit of the new version. > The upgrade would start at 8:00AM(E.T.) and is expected to take > 8hours on Wed, Aug 26, 2009. > > The subversion service and trac websites services would NOT be > available during the following time period. > > Date: Wed, Aug 26, 2009 > Time: > - 5:00am-1:00pm Pacific US time > - 6:00am-2:00pm Mountain US time > - 7:00am-3:00pm Central US time > - 8:00am-4:00pm Eastern US time > - 12:00pm-8:00pm GMT > > Meanwhile, I will upgrade trac-0.11 to 0.11.5 during this downtime > too. > > Please let me know if you have any concerns or questions about this > upgrade. > > Regards, > > -- > - DongInn How will this interact with the boost release schedule? -- Marshall

2 1

[range] [1.40] iterator_range::size broken for non-random access iterators
by Ryan Gallagher 21 Aug '09

21 Aug '09

We were just upgrading from 1.34.1 to 1.39.0 and I ran into this issue which I note is still in the trunk (and I would assume the 1.40 candidate). The definition of iterator_range::size is using operator- where it should be using std::distance as it did in boost 1.34 days: """ difference_type size() const { BOOST_ASSERT( !is_singular() ); return m_End - m_Begin; } """ It used to be: """ #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) return std::distance<IteratorT>( m_Begin, m_End ); #else return std::distance( m_Begin, m_End ); #endif """ I'm not sure why it would have changed but it's no longer working with bi-directional iterators, etc. Can we put back the old version? Can we get this fixed for 1.40? Thanks, -Ryan

2 5

Checking for return types (result_of) - redux..
by Edward Grace 21 Aug '09

21 Aug '09

Dear all, So, I have nearly figured out what to do, however it seems -- deliberately in fact, that the behaviour of result_of<???> is different when passed a function and a functor. Though I am not sure, the documentation: http://www.boost.org/doc/libs/1_39_0/libs/utility/ utility.htm#result_of "When F is a class type with a **member type result_type**, result_of<F(T1, T2, ..., TN)> is F::result_type." appears to imply that this is the way it should be (emphasis mine). So does the following in fact, http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html So it seems that my original instinct (it's hard) was correct after all. Surely result_of<functor()>::type should resolve to the result type in the same way as it does for anything else callable (like a function). Anything else seems to be a big fat pain in the rear... Or, put another way, can I get what I want? Example below, the problem is s.member_function(one). Help! -ed #include <boost/mpl/assert.hpp> #include <boost/utility/result_of.hpp> #include <boost/type_traits/is_same.hpp> void void_f() {} unsigned unsigned_f() { return 1; } // We want member_function to accept any callable object (functor, // function pointer) thing that returns an unsigned integer. // // value = f(); // // Should work. struct S { template <class O> void member_function(O f) { // We require that the function/functor f returns an unsigned integer. BOOST_MPL_ASSERT( (boost::is_same<unsigned, typename boost::result_of<O()>::type>) ); unsigned sum(0); sum += f(); } }; struct one_functor { // This is apparently needed if we want to use result_of<..> on nullary functors like this. // typedef unsigned result_type; unsigned operator()() { return 1; } }; int main() { S s; one_functor one; unsigned val=one(); // We can assign to the val from the // instantiated functor. // THIS DOES NOT WORK AS IT SHOULD... s.member_function(one); // This does not work as // boost::result_of<O()> is, apparently // one_functor instead of unsigned // // Uncommenting the typedef in one_functor makes it // work - but it seems like a right pain in the rear. s.member_function(unsigned_f); // Works fine. // s.member_function(void_f); // Dies as it should! return 0; }

5 12

[1.40] OK to patch docs on release branch?
by John Maddock 21 Aug '09

21 Aug '09

Is it still Ok to patch the docs on the release branch? I have one small patch for the Boostbook docs (currently they produce invalid Docbook XML :-( ), and one for the doc/pdf/Jamfile.v2. Cheers, John.

2 2

[1.40] Any new libraries in 1.40?
by John Maddock 21 Aug '09

21 Aug '09

Are there any new libraries in 1.40 that need their docs adding to the PDF build? If there are then they need to be added to the release notes as well BTW... Just double checking yours, John.

2 2

graph_parallel
by Vladimir Prus 21 Aug '09

21 Aug '09

I notice that release branch now has libs/graph_parallel. I have a couple of questions about that: 1. I don't see any mention of this addition at http://beta.boost.org/users/news/version_1_40_0 Jeremiah, unless I've missed something, would you please add something to release notes? 2. Normally, directories under libs/ correspond to libraries. I do not see any review for new library called graph_parallel on: http://www.boost.org/community/review_schedule.html, which suggest to me this is actually part of Boost.Graph libraries. Why does it have top-level directory? Thanks, Volodya

2 1