- Boost - lists.boost.org

[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

Checking for return type -- BOOST_STATIC_ASSERT?
by Edward Grace 21 Aug '09

21 Aug '09

I'd like to be able to make certain that a function/functor returns a double precision floating point value. I was always under the impression that it's essentially impossible to check things based on return type. Is there a way to do this? Something like BOOST_STATIC_ASSERT, who knows perhaps that *can* do it.. Ideally I would like to have some sort of compile type warning so that in the following context, class myclass { public: ... template <class O> a_func(O functor) { ASSERT_IS_A_FUNCTOR(O); ASSERT_RETURN_TYPE_CONVERTABLE_TO_FLOAT(O); } }; if O is compatible with the concept of a functor and O returns a type that can be converted to a float, then we are good to go -- otherwise I'd like an intelligible error. If, for example, O is of the type 'void (*)()' I'd like it (the compiler) to spit out, "The function pointer of type O must of signature float (*)()" Any ideas? -ed ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997

4 8

Re: [boost] [interprocess] SHARING_VIOLATION due to antivirus
by raindog＠macrohmasheen.com 21 Aug '09

21 Aug '09

I can confirm that I received your message twice. ------Original Message------ From: Isidor Zeuner Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Aug 20, 2009 9:21 PM Subject: Re: [boost] [interprocess] SHARING_VIOLATION due to antivirus > Quoting Lars Hagstrom <lars(a)update.uu.se>: > > > Yes, of course it is due to bad AV. But for me it would still be handy > > if boost.interprocess was a little bit more tolerant towards that. If my > > software crashes it will be perceived as buggy, however much I blame AV... > > One thing you can do is to, at startup, detect if nod32.dll is loaded in your > process, and throw up a warning dialog to tell the user that the AV software is > buggy. > This seems inappropriate since, if anything, the operating system kernel which forces user space programmers into busy waiting for obtaining locks could be considered buggy by design in that regard. However, this bug could even be warned about at compile time, so we could solve this in boost itself. It is probably inappropriate to do so by default, but for administrators of heterogenous systems it might become handy to have a preprocessor flag which can warn if someone is about to deploy software which uses features the operating system was not designed for, so it can be considered to move the application to a more appropriate platform. Best regards, Isidor PS: The moderation software of this list seems to be broken. I sent this message before, received a "...was successfully received by the Boost mailing list" acknowledgement after a while, but over 12 hours later the message is still neither "successfully received", nor have I got any new status information. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

2 1