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