Re: [boost] [iterator] [property_map] Enhancement proposals

Subject: Re: [boost] [iterator] [property_map] Enhancement proposals
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-10-07 23:02:42

On Sat, Sep 29, 2012 at 9:29 AM, Louis Dionne <louis.dionne92_at_[hidden]>wrote:

> Dear boost,
>
[...]

> The object of this message is to collect feedback on several enhancement
> proposals I have prepared for two existing libraries:
>
> [boost.iterator]
> [boost.iterator.accessor_iterator]
> The accessor_iterator is an iterator adaptor that returns a reference to a
> member of its pointee when dereferenced. I see it as another step in the
> direction of easier iterator composition, which has helped me writting less
> code in the past.
>

Regarding accessor_iterator: The implementation is very short, but it still
seems to have minimal if any advantage to just using a transform_iterator
directly composed with a function object wrapping the pointer-to-member
(either at runtime or compile-time [1]). Also, seems you're lacking a
convenient make_accessor_iterator (which, of course, would probably have to
be a macro, as described in [1]).

> [boost.iterator.chained_output_iterator]
> The chained_output_iterator is an iterator adaptor allowing to apply a
> functional transformation to a value before outputing it into another
> output
> iterator. It is much like a function_output_iterator that would forward its
> result to another output iterator. It allows for cool stuff like creating a
> pipeline of operations without having to create temporary storage.
>

This could be useful, but there's a few things I need to understand about
your implementation first.
- Using is_convertible to determine iterator convertibility is, strictly
speaking, too loose, as it allows derived* -> base* conversions that are
undesirable if sizeof( derived ) > sizeof( base ). At some point I probably
need to fish through the Iterator library and change any such uses myself...
- I'm wondering why the increment of the wrapped iterator happens inside
proxy::operator= rather than chained_output_iterator::operator++...? Also,
typically operator* is a const member function, and moving the advancement
of the wrapped iterator into chained_output_iterator::operator++ would
allow that. I might be missing something though.

[...]

> All the code is available on github:
> https://github.com/ldionne/boost-submissions
>
> To see how each class can be used, you may look at the unit tests for the
> corresponding class.
>
> If anything is accepted, I will be pleased to write documentation and
> examples
> for the concerned feature and to integrate it into the existing
> documentation.
>
> Looking forward to your feedback,
>
> Louis Dionne
>

- Jeff

[1]
http://www.boost.org/doc/libs/1_51_0/libs/function_types/example/fast_mem_fn.hpp