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-09-29 14:32:56

[Speaking as one of the maintainers of the Iterator library only...]

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

> Dear boost,
>
> First of all, let me quickly introduce myself as this is my first post
> here:
> I am a 20 years old programming enthusiast with interest for
> metaprogramming,
> functional programming and library design. I also have a strong will to
> contribute to open source projects since I love the philosophy behind it
> and
> it is a great way to develop new skills and to work with talented people.
>

Welcome!

> 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.

> [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.
>
[...]

Both of these sound like useful additions; I think it makes more sense to
build these on top of transform_iterator and function_output_iterator
directly in some fashion. In other words, I can see 3 ways of effecting the
above (and I'm not sure which you've chosen, as I haven't looked at your
code submission yet): create a new iterator independent of existing
iterators; use iterator_adaptor to adapt an existing iterator; or provide
a, e.g., a make_access_iterator function, which returns, e.g., a
transform_iterator< mem_fn_t< PtrToMemFn >, BaseIterator > (so no actual
new iterator types are provided, just convenience functions). I don't
really see a point in doing the first, and the last should require the
least amount of additional code.

I'll take a glance at your code this weekend and likely have more targeted
comments.

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.
>

Always a plus :)

- Jeff