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

Request to merge r61263 into release branch
by Jeremiah Willcock 28 Apr '10

28 Apr '10

It's another begin/end disambiguation patch to fix VC++ 10 issues. -- Jeremiah Willcock

3 5

Concept check and __LINE__
by Matthew L. Creech 28 Apr '10

28 Apr '10

I made some trivial changes in a header file today, and suddenly it refused to compile, throwing out boost::concept_check errors. Here's an example error: In file included from /home/mlcreech/work/PCM-tk/etn_export/include/translator++.hpp:193, from ../../common/source/main.cpp:8: /home/mlcreech/work/PCM-tk/etn_export/include/translator/handle.hpp:119: error: conflicting declaration ‘typedef struct boost::concept::detail::instantiate<boost::concept::requirement<Model>::failed [with Model = toolkit::translator::Callable<toolkit::translator::CHandle<toolkit::translator::CValArray<toolkit::translator::CSimpleVal<double> > > >]> toolkit::translator::boost_concept_check119’ /home/mlcreech/work/PCM-tk/etn_export/include/translator/concept/translatable_archetype.hpp:119: error: ‘toolkit::translator::boost_concept_check119’ has a previous declaration as ‘typedef struct boost::concept::detail::instantiate<boost::concept::requirement<Model>::failed [with Model = toolkit::translator::Translatable<toolkit::translator::translatable_archetype<boost::null_archetype<int> > >]> toolkit::translator::boost_concept_check119’ make[3]: *** [translate++] Error 1 I had no idea what this was about, but then I went to look up where the supposed conflicts were and noticed that they were both on line 119. As it turns out, I have 2 different header files which have BOOST_CONCEPT_ASSERT() for different concepts at line 119. It seems that Boost internally generates some global names based on the line number, so it creates 2 identially-named enum definitions. From "boost/concept_check/general.hpp": # define BOOST_CONCEPT_ASSERT( ModelInParens ) \ enum { BOOST_PP_CAT(boost_concept_check,__LINE__) = \ ::boost::concept_check_<void(*) ModelInParens>::instantiate \ } Off-hand I'm not sure how to fix this in Boost (maybe some preprocessor tricks based on __FILE__?), but it seems like it should at least be documented as a limitation. Or maybe there's some other way of using BOOST_CONCEPT_ASSERT() that works around this? Obviously the immediate fix is trivial - add a few blank lines. I just thought I'd bring it up in case others hit the same problem. Thanks -- Matthew L. Creech

4 3

[handling mini-reviews] do we need formal scheduling for this?
by Thorsten Ottosen 28 Apr '10

28 Apr '10

Dar Boosters, Erwann has implemented some cool extensions to Boost.Assign that we would like to include. For example, his work allows code like A list of references (to temporaries, in this example): boost::array<int,9> a = cref_csv( 1,5,3,4,2,9,0,7 ) Chained ranges: vector<int> v = vector<int>( 3,1 ) && vector<int>( 3,2 ) && vector<int>( 3,3 ); See https://svn.boost.org/svn/boost/sandbox/statistics/support/boost/assign/ and https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/ for more info. I think the right thing to do is to make a mini-review. Do we need a special schedule for such reviews or should we just proceed with an announcement on the user and dev list? -Thorsten

2 1

[1.43.0] Release schedule
by Beman Dawes 28 Apr '10

28 Apr '10

The question came up as to whether 1.43.0 is still open for bug fixes. The answer is, yes, with permission from one of the release managers. My rationale is that there are still an uncomfortable number for test failures, and so taking a few more days to clear more failures is well worthwhile. The release is currently scheduled for next Monday, but I'm guessing release may run a few days later than that. --Beman

4 3

[async] withdrawn
by Scott Woods 28 Apr '10

28 Apr '10

Hi Boost, To prevent any further related effort, the library previously offered for review is withdrawn. Vicente explained why my work would need re-licensing and conversion to Boost componentry. Robert explained why the library is not a proper candidate for acceptance into Boost. I respect both of these positions. However, re-licensing and conversion then has little purpose. Regards, Scott

1 0

Library proposal: odeint
by Karsten Ahnert 28 Apr '10

28 Apr '10

Hi, some months ago, I proposed a library for solving ordinary differential equations, which can be found at http://svn.boost.org/svn/boost/sandbox/odeint/ Is it possible to add odeint to the Libraries Under Construction page? Best regards, Karsten

2 3

[range][1.43] Range Algorithms clasification
by vicente.botet 27 Apr '10

27 Apr '10

Hi, The documentation of the range library contains the following sections for Range Algorithms: * Introduction and motivation * Mutating algorithms * Non-mutating algorithms * Set algorithms * Heap algorithms * Permutation algorithms * New algorithms * Numeric algorithms I don't find the clasification enough clear in particular we can find a New algorithms section with the following algorithms * erase * for_each * insert * iota * overwrite * push_back * push_front * remove_erase * remove_erase_if Shouldn't these algorithms be included on the other cathegories? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

[range][1.43] mismatch doc
by vicente.botet 27 Apr '10

27 Apr '10

The documentation of the mistmatch function contains several errors. The prototypes return a pair of iterators, but the description talk about The versions of mismatch that return an iterator or a range_return. Could this be improved for 1.43 release or it is better I make a ticket? "Description The versions of mismatch that return an iterator, return an iterator to the first position where rng1 and rng2 differ. Equality is determined by operator== for non-predicate versions of mismatch, and by satisfying pred in the predicate versions. The versions of mismatch that return a range_return, defines found in the same manner as the returned iterator described above." Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

[range] Check if one sequence is a rotation of other sequence.
by vicente.botet 27 Apr '10

27 Apr '10

Hi I want to define a function is_rotation that check if a sequence is a rotation of another using the following algorithm: a.. First make sure s1 and s2 are of the same length. b.. Check to see if s2 is a substring of s1 concatenated with s1. I have started to implement this using boost range, using the join view to avoid the phisical concatenation but I'm not sure that testing 'boost::search(boost::join(s1,s1), s2) != end(boost::join(s1,s1))' is the best way to do with Boost.Range. bool is_rotation(std::string const &s1,std::string const &s2) { return (boost::size(s1) == boost::size(s2)) && boost::search(boost::join(s1,s1), s2) != end(boost::join(s1,s1))); } Sugestion for improvement? Best regards, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

[System] Non-standard code in error_code_user_test
by Doug Gregor 27 Apr '10

27 Apr '10

The code in lib/system/test/error_code_user_test.cpp attempts to default-initialize a const-qualified variable non-POD class type that does not have a user-declared default constructor, which is ill-formed per C++03 [dcl.init]p9 (C++0x [dcl.init]p6). The attached patch fixes the problem be introducing a user-declared default constructor for two of the types we're testing with. - Doug

1 0

[fiber] With MSVC71
by Chard 27 Apr '10

27 Apr '10

I was hoping to try the latest fiber library from the vault, but it currently does not compile successfully with MSVC71. Is it the intention to support this compiler? There are two compilation failures: fiber/strategy.hpp, lines 77-8 template< typename Callable > friend void this_fiber::at_fiber_exit( Callable); I believe this is a VC71 compiler bug; the forward declaration of a template function that is subsequently given friend access to a class does not seem to work. I don't know the workaround. The other can be trivially fixed, and should not cause any issues on other compilers. Here's the patch: --- X:/Old/boost/libs/fiber/src/fiber.cpp Fri Apr 09 19:33:08 2010 +++ X:/New/boost/libs/fiber/src/fiber.cpp Fri Apr 23 11:41:58 2010 @@ -90,7 +90,7 @@ return * this; } -fiber::operator unspecified_bool_type() const +fiber::operator fiber::unspecified_bool_type() const { return info_; } bool

1 0

Re: [boost] VC10 config - some regressions in several libraries
by Brian Wood 27 Apr '10

27 Apr '10

> I've made a note to myself to request that /Za be removed or at least deprecated in VC11 > (our command-line deprecation warnings aren't silenceable, so they're pretty effective). [ snip] Please don't top post and please trim quotes to make things less cumbersome. Regards, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Color of nodes in Edmonds & Karps max flow algorithms.
by Dan Jiang 27 Apr '10

27 Apr '10

Hi All, I have a question: What is the color(s) of nodes that can still be labeled after max flow is found in the Edmonds and Karp's algorithm? Are they black AND grey or just black? I know black nodes can still be labeled, what about nodes with grey color? -Thanks, Dan _________________________________________________________________ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465

2 1

Boost.thread compile error with SunCC 5.9
by Frank Meerkötter 27 Apr '10

27 Apr '10

Hi, I am trying to use boost.thread with the version 5.9 of the sun compiler. I encountered an error during compilation which already has been reported by Urs Stotz some weeks ago. He also supplied a patch for this issue. http://lists.boost.org/Archives/boost/2010/02/161801.php The patch works for me. I wonder if it could be applied for 1.43? Kind Regards, Frank

3 3

[GSoC] Student Proposals
by Andrew Sutton 27 Apr '10

27 Apr '10

Hi All, I'd like to start by thanking all of the students who are interested in working on the Boost C++ Libraries and submitted proposals. Unfortunately, we can't fund every proposal we received (about 85), and the competition for available funding slots (only 10) is very competitive. We carefully reviewed every proposal based on the merits and feasibility of the work described. If your proposal was not accepted, that does not mean that it was without merit. We encourage all students to continue participating with the Boost community as users and developers, regardless of the results of this program, and look forward to seeing new proposals next year. If you are interested in feedback about your proposal's review and how you can improve the competitiveness of your submissions, feel free to contact me directly. Having said that, congratulations to the students whose projects were accepted. I will be sending out instructions soon on getting started and up to speed with the Boost development infrastructure, Subversion, mailing lists, etc. I'm will be posting the instructions to the Boost developers mailing list (not users!). If you are a student whose project was accepted, you need to subscribe to the Boost developer's mailing list [1]. I'd also like to thank all of the mentors for helping with the ranking and assignment of student projects. Thanks again and best regards, Andrew Sutton andrew.n.sutton(a)gmail.com [1] http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[GSoC] Implementation of arbitrary precision integers (BigInts)
by Adam Smith 27 Apr '10

27 Apr '10

Hi, First of all, I'd like to extend thank you to whoever chose my proposal - it's a great honour, and I'm very excited to contribute to Boost. Just a few questions to start with; these are primarily for my mentor (Rene Rivera), I guess, but of course others could chime in. Will most communication happen on the mailing lists or on #boost or #boost-soc? If the latter, roughly what time of day should I be online? Alternatively, would direct e-mail communication be preferred? Are there any particular documents I should read? Any preliminary tasks that I should do? Thanks again for accepting my proposal! Adam

2 1

[1.43] regex build files
by Richard Hazlewood 27 Apr '10

27 Apr '10

Reminder; you might want to update the stand-alone makefiles in /branches/release/libs/regex/build Is it worth continuing with these? Seems like an unnecessary maintenance overhead, especially given that bjam seems to do it all. Chard.

2 1

fixing the compilation of the math lib on HPUX
by Frank Meerkötter 27 Apr '10

27 Apr '10

Hello, I am currently trying to build boost with the HP aCC (aCC: HP C/aC++ B3910B A.06.12 [Nov 03 2006]). The build fails for the tr1 math lib. [...] acc.compile.c++ bin.v2/libs/math/build/acc/release/threading-multi/copysign.o "libs/math/build/../src/tr1/copysign.cpp", line 16: error #2247: function "copysign(double, double) C" has already been defined extern "C" double BOOST_MATH_TR1_DECL copysign BOOST_PREVENT_MACRO_SUBSTITUTION(double x, double y) ^ 1 error detected in the compilation of "libs/math/build/../src/tr1/copysign.cpp". [...] acc.compile.c++ bin.v2/libs/math/build/acc/release/threading-multi/copysignf.o "libs/math/build/../src/tr1/copysignf.cpp", line 16: error #2247: function "copysignf" has already been defined extern "C" float BOOST_MATH_TR1_DECL copysignf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) 1 error detected in the compilation of "libs/math/build/../src/tr1/copysignf.cpp". [...] "libs/math/build/../src/tr1/fmaxf.cpp", line 16: error #2247: function "fmaxf" has already been defined extern "C" float BOOST_MATH_TR1_DECL fmaxf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) ^ 1 error detected in the compilation of "libs/math/build/../src/tr1/fmaxf.cpp". acc.compile.c++ bin.v2/libs/math/build/acc/release/threading-multi/fminf.o "libs/math/build/../src/tr1/fminf.cpp", line 16: error #2247: function "fminf" has already been defined extern "C" float BOOST_MATH_TR1_DECL fminf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) ^ 1 error detected in the compilation of "libs/math/build/../src/tr1/fminf.cpp". In all cases the code causing the problems looks somewhat like this: #if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) extern "C" float BOOST_MATH_TR1_DECL fminf BOOST_PREVENT_MACRO_SUBSTITUTION(float x, float y) #endif [...] So it looks like someone already took some precautions against this problem. My compiler is slightly older (61200 vs. 61400). When i replace the 61400 at these four places with a 61000 my build completes just fine. ./libs/math/src/tr1/copysign.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) ./libs/math/src/tr1/copysignf.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) ./libs/math/src/tr1/fmaxf.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) ./libs/math/src/tr1/fminf.cpp:#if !(defined(__HP_aCC) && (__HP_aCC >= 61400)) Can anybody more experienced with the aCC tell me if such a change would be a good idea? Would you accept a patch? Frank

2 3

Re: [boost] [1.43][Serialization] Serialization library seriosly broken
by Hartmut Kaiser 27 Apr '10

27 Apr '10

> Hartmut Kaiser wrote: > >> I've just made a change in void_cast.cpp. I tested it here and > >> checked > > into > >> the trunk(61546). > >> > >> Could you test this change ASAP? > > > > I will be able to test tomorrow evening only, but I definitely will > > test. > > > > Regards Hartmut > > You might want to check the change I made as well. The assert exists in 1.42 > - the only difference in the file - void_cast.cpp is a small change I made to fix > a memory leak. I'm not confident that my fix actually fixed it - but of course > everything passes here. I'm sorry to say I recompiled everything against Boost trunk (rev. 61561), but the problem still persists. I don't understand what's going on, but I doubt it's a problem directly in void_cast.cpp. For some reason the type I described gets registered more than once (definitely from different modules, although dynamically loaded, none gets unloaded before the assertion). Did you change anything related to auto-type registration? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

4 8

[1.43] Beta build of PDF docs available.
by John Maddock 27 Apr '10

27 Apr '10

A PDF build of the docs for Boost-1.43-beta is now available from https://sourceforge.net/projects/boost/files/boost-docs/1.43.0/boost_pdf_1_… If library authors with quickbook/boostbook docs could take a look and check for SNAFU's that would be great. Enjoy, John.

2 2

[1.43] [MPL] Okay to merge fix for bug #1992 to the release branch?
by Aleksey Gurtovoy 27 Apr '10

27 Apr '10

Changeset: https://svn.boost.org/trac/boost/changeset/60888 The fix is a low-risk one liner that has been committed to the trunk about a month ago (without any disturbance). Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

[1.43] [MPL] Okay to merge gcc 4.5 fix to the release branch?
by Aleksey Gurtovoy 27 Apr '10

27 Apr '10

Changeset: https://svn.boost.org/trac/boost/changeset/61467 As predicted, the fix did not break anything in the trunk. Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

[sandbox] Request for Account
by Murilo Adriano Vasconcelos 26 Apr '10

26 Apr '10

Hello, I am one of this year GSoC students and i want an account in sandbox. How do I have to proceed? Best, -- Murilo Adriano Vasconcelos Ciência da Computação Universidade Federal de Goiás http://murilo.wordpress.com

2 1

Automatic differentiation (and complex numbers) with lazy component evaluation
by Hal Finkel 26 Apr '10

26 Apr '10

Hello, I've uploaded to a subversion repository on SourceForge my Lazy Types library. This library provides template classes for dual numbers (used for automatic differentiation) and complex numbers. Expression templates are used in order to evaluate only those components which are actually needed. All of the standard-library math functions (and arithmetic operators) are supported. http://lazytypes.sourceforge.net/ http://sourceforge.net/projects/lazytypes The dual-number formalism is especially useful because it enables the compiler to generate analytic expressions for the derivative of "any" function (where "any" is restricted to those functions which compute using operators and functions the library knows about, which include all of the standard ones). These are *not* finite-difference approximations, but exact answers (to machine precision). Functions which use conditional statements, loops, etc. are fine, although the derivative might not have a meaning if evaluated at a point of discontinuity. This code has been released under the BSL 1.0. Although some Boost headers are used (enable_if, type_traits, etc.), Boost.Proto is not used. Is there any interest in having these libraries in Boost: 1. As-is (plus more documentation, tests, namespace change, etc.) 2. Only if rewritten to use Boost.Proto (which I am willing to do, so long as the performance of the current implementation can be matched). The project Wiki page (to which http://lazytypes.sourceforge.net/ redirects) has some documentation and usage examples. Here is a quick example of taking the derivative (and the second derivative) of a multivariate function: #include <lazy_types.hpp> namespace lt = lazy_types; ... template <typename X> X f(X &v1, X &v2) { using namespace lt; return pow(v1, 3) + pow<3>(v1) + pow<2>(v2 + v1) + v2*v1/5.0 + 3.0; } // A pow<> template is provided which works with the expression-template types. ... lt::dual<double, 2> fv1(2.0, 0), fv2(4.0, 1); lt::dual<double, 2> fv = f(fv1, fv2); std::cout << fv << " " << fv.eps(0) << " " << fv.eps(1) << std::endl; // This computes the derivative of the function f with respect to both of its arguments evaluated at the point where the function itself has been evaluated. // An example of computing the second derivative: template <typename X> X df(X &v1, X &v2, size_t ei) { lt::dual<X, 2> d1(v1, 0); lt::dual<X, 2> d2(v2, 1); return f(d1, d2).eps(ei); } lt::dual<double, 2> df0 = df(fv1, fv2, 0); lt::dual<double, 2> df1 = df(fv1, fv2, 1); std::cout << df0.eps(0) << " " << df0.eps(1) << std::endl; std::cout << df1.eps(0) << " " << df1.eps(1) << std::endl; If there is interest in adding these types (or some rewritten version of them) to Boost, please let me know, and I'll work on getting the library ready for review. Sincerely, Hal Finkel

3 4

[asio] how to handle "boost::asio::placeholders::error" in "boost::function"?
by 曹亚文 26 Apr '10

26 Apr '10

Hi all, I met a problem which can't be solved. Can any kind people help me? The code looks like the below: class transfor_data { public: void one_fun( const boost::system::error_code& e, connection conn ) { ... } void another_fun() { { //compile error because of the placeholder boost::function<void(void)> fun = boost::bind(&transfor_file_push::write_file, this, boost::asio::placeholders::error, conn); } { //fine without placeholder boost::system::error_code e; boost::function<void(void)> fun = boost::bind(&transfor_file_push::write_file, this, e, conn); } } }

3 2