September 2012 - Boost-users

boost 1.51.0 bz2 archive observations
by Aras Vaichas 03 Sep '12

03 Sep '12

Sorry for the cross-posting, but I'm not sure where to put this. There is a slight difference between the 1.51.0 and 1.50.0 boost bz2 files. e.g. \boost_1_50_0.tar.bz2\boost_1_50_0.tar\boost_1_50_0\ \boost_1_51_0.tar.bz2\boost_1_51_0.tar\.\boost_1_51_0\ I went looking for this because I updated the Boost version to 1.51.0 in Buildroot and it failed to find the bootstrap.sh file because it wasn't in the expected directory. e.g. /opt/br/output/build$ find -name "bootstrap.sh" ./boost-1.51.0/boost_1_51_0/tools/build/v2/bootstrap.sh ./boost-1.51.0/boost_1_51_0/bootstrap.sh ./boost-1.50.0/tools/build/v2/bootstrap.sh ./boost-1.50.0/bootstrap.sh Buildroot fails to find the boostrap.sh file and the build fails. When I tried to untar it manually I got an error. $ tar xjf boost_1_51_0.tar.bz2 tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-t: Operation not permitted tar: Exiting with failure status due to previous errors 1.50.0 does not have this problem. regards, Aras Vaichas

2 1

[fusion] push_back documentation issue
by Agustín K-ballo Bergé 03 Sep '12

03 Sep '12

The documentation for push_back specifies a return type of result_of::push_back<Sequence, T>::type where Sequence is not const-qualified: template< typename Sequence, typename T > typename result_of::push_back<Sequence, T>::type push_back( Sequence const& seq, T const& t); yet the implementation is defined to return result_of::push_back<Sequence const, T>::type, note the const-qualified Sequence: template <typename Sequence, typename T> inline typename lazy_enable_if< traits::is_sequence<Sequence> , result_of::push_back<Sequence const, T> >::type push_back(Sequence const& seq, T const& x) Is this a documentation bug? Agustín K-ballo Bergé.- http://fusionfenix.com

2 1

[Range] Proposal to add a new range adaptor (first_nd), or modify sliced
by Gábor Márton 01 Sep '12

01 Sep '12

Hi, Problem: Get the first N element of a SinglePassRange. It is not possible with sliced, because it requires RandamAccessRange. (Similar discussion was on the list about this in 2011 January: http://lists.boost.org/boost-users/2011/01/65757.php) Possible solutions: A) Modify sliced implementation to use std::advance instead of boost::size. (Boost::size calls operator+ on the end iterator of the adapted range, that is why it requires the random access.) However using std::advance is not efficient in case of iterators which are not random access ones. I think this efficiency problem is the reason why the author(s) decided to not use std::advance, but rather boost::size. So this is not a real solution. B) Introduce a new range adaptor, which has an underlying adapted iterator with a "count" member: template <class Iterator> class first_n_iterator : public boost::iterator_adaptor<first_n_iterator<Iterator>, Iterator> { ... first_n_iterator(const Iterator& it, std::size_t n) : first_n_iterator::iterator_adaptor_(it), initial(it), count(n) {} ... void increment() { ++(this->base_reference()); ++count; } bool equal(first_n_iterator const& other) const { return this->initial == other.initial && this->count == other.count; } Iterator initial; // used to be able to differentiate ranges std::size_t count; }; One can find the whole solution and the test for it attached (first_nd.hpp, first_nd_test.cpp). I think this is more effective than a sliced implementation with std::advance would be. The structure first_nd could be changed to support two parameters, so one could provide the start position too (so it wouldn't be fixed to zero). In the implementation (first_nd_range) std::advance could be used to point the starting iterator to the start position. However in this case we would get the same functionality as slice now has ... I am asking the boost community, 1) Would it be useful, to have such a new range adaptor? If yes, -- what would be the best name for it (first_nd is not the best, I know) ? -- I would be pretty enthusiastic to contribute it to boost. 2) Are the upper arguments valid against the current implementation of sliced? If yes, would it worth to change it to a similar to first_nd one? Or maybe, it would even be better to specialize sliced_range based on the iterator_tag of the range, what do you think? Best Regards, Gabor

7 7