
On Sat, Sep 29, 2012 at 9:29 AM, Louis Dionne <louis.dionne92@gmail.com>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...