I have thought a bit about this issue. would there be a general interest in a boost.iterator conforming implementation of stl algorithms? On 2012-10-16 14:40, Jeffrey Lee Hellrung, Jr. wrote:

On Tue, Oct 16, 2012 at 3:25 AM, Oswin Krause wrote:

...

Hi,

I often have problems which look a bit like this:

    //example code, only for problem statement     //std::vector<bool> chosen only because it is no container :). If this is too silly for you,     //think about a matrix interpreted as range of row-vectors.     std::vector<bool> myContainer;//does only have proxy iterators.     std::vector<double> myDistances; //stores for every element in myContainer a distance

    //now i want to to sort the elements of both ranges in place     //as if they were in a hypothetic range std::vector >     //and sort them by the second part:     boost::sort(make_key_value_range(myContainer,myDistances));//bam, not allowed

I omited the definition of make_key_value_range but it should be clear that this returns a proxy range with writable iterators and reference type similar to std::pair for which swap is overloaded to do the right thing.

You should be able to equally well use zip_iterator's, or, if supported by Boost.Range, something like a make_zip_range.  

...

This is not allowed by the standard as boost::sort calls std::sort which in turn requires random_access_iterators - and they disallow proxy references.

Ugh, yes :(

Links: ------ [1] mailto:Oswin.Krause@ruhr-uni-bochum.de [2] http://en.wikipedia.org/wiki/Introsort

Hi, yes, this was indeed my idea. it should be quite easy to check whether the class is an "old-style iterator" or "new style iterator" and call the standard implementation if this is applicable. I would branch using is_same< remove_const::type>::type, iterator_value<X>::type

(i.e. underlying type of X::reference is X::value_type) In my opinion, this would give real value to boost.range aside from the smarter interface :) On 2012-10-17 13:33, Jeffrey Lee Hellrung, Jr. wrote:

On Tue, Oct 16, 2012 at 11:08 PM, Oswin Krause wrote: [...]

...

would there be a general interest in a boost.iterator conforming implementation of stl algorithms?

I think any STL-like algorithms should be added to Boost.Range's existing collection of algorithms. I've personally found range interfaces to such algorithms (when appropriate) are significantly more convenient and easier to read.

It's possible, for example, that a given algorithm can use the one in the STL when the iterators are conforming standard iterators or when Boost detects the underlying STL implementation relaxes the standard requirements on iterators (e.g., does not actually require the reference type to be a real reference); and otherwise dispatch to a Boost-provided implementation.

Perhaps the present Boost.Range maintainer (Neil Groves, I believe?) can comment.

- Jeff

Links: ------ [1] mailto:Oswin.Krause@ruhr-uni-bochum.de

AMDG On 10/17/2012 05:13 AM, Ronny Herzog wrote:

Dear all,

I have a simple Jamroot file for which I don't know why it does not work. Bjam is always complaining:

error: Unable to find file or target named error: '/boost/filesystem//fs' error: referred from project at error: '.'

However, since I use "use-project boost : c:/boost_1_50_0 ; ", I would assume that it would find it easily.

It would find it if you used the correct name: /boost/filesystem//boost_filesystem or, /boost//filesystem In Christ, Steven Watanabe P.S. Please don't reply to an existing thread with a new subject. Start a new thread instead.

Hi,

C++ requires it to be `iterator_traits<Iterator>::reference`, I thought, or does it require it to be real reference like `iterator_traits<Iterator>::value_type&`?

The first is a requirement for every iterator. However, there are a few more lines written in pure standardese which are described in the boost.iterator docu: http://www.boost.org/doc/libs/1_51_0/libs/iterator/doc/new-iter-concepts.htm... "Value Access Requirements in Existing Iterator Categories: [..] Forward Iterator *i is T&" where T is the value_type of the iterator. Greetings, Oswin