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-13 19:36:38

On Sat, Oct 13, 2012 at 4:25 PM, Louis Dionne <louis.dionne92_at_[hidden]>wrote:

> Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> writes:
>
> > > Accepting any iterator that is convertible to the wrapped iterator is
> nice
> > > if it is not dangerous because it allows to do this:
> > >
> > >     typedef chained_output_iterator<Functor1,
> > >                 chained_output_iterator<Functor2,
> > >                     std::back_insert_iterator<std::vector<T>>>>
> OutIter;
> > >     // Then, if Functor1 and Functor2 are default constructible:
> > >     std::vector<T> vec;
> > >     OutIter result(std::back_inserter(vec));
> > >
> > > If the constructor only takes an instance of the wrapped iterator, the
> > > following must be done, which could be annoying if one creates a long
> > > chain:
> > >
> > >     typedef chained_output_iterator<Functor2,
> > >                 std::back_insert_iterator<std::vector<T>>> Chain;
> > >     typedef chained_output_iterator<Functor1, Chain> OutIter;
> > >     std::vector<T> vec;
> > >     OutIter result(Chain(std::back_inserter(vec)));
> > >
> > > So I would advocate in favor of keeping the initial implementation for
> the
> > > first two constructors, unless I am missing something.
> > >
> >
> > Wouldn't the first block of code above not compile regardless of whether
> > the unary constructor is a template constrained by enable_if<
> > is_convertible > or takes the wrapped iterator directly? The result of
> > std::back_inserter(vec) is not convertible to the intermediate
> > chained_output_iterator in either case.
>
> Yes, the first block of code compiles. Let's say we have:
>
>     typedef std::back_insert_iterator<std::vector<T> > Third;
>     typedef chained_output_iterator<Functor2, Third> Second;
>     typedef chained_output_iterator<Functor1, Second> First;
>
> Third is convertible to Second:
>
>     template <typename Iterator>
>     Second(Iterator const& iterator,
>            typename enable_if_convertible<Iterator, WrappedIter>::type*
> =0);
>

I seemed to remember this constructor was explicit. If it isn't, it should
be. If you want convenience, I would think it sufficient for
make_chained_output_iterator to take multiple function objects. Or provide
some component that can conveniently compose multiple function objects...
(Boost.Bind and Boost.Phoenix can do this, I think, but it could probably
be specialized to reduce the syntactic weight).

[...]

> > Best (i.e., least work for me) would be to provide the header, the unit
> > test, any patches to the present Boost.Iterator documentation, and a
> > contract signed in blood that you'll support this for life. Well, okay,
> > I'll take 3 out of 4 :)
> >
> > Where you make the files available doesn't matter too much, just as long
> as
> > I can easily grab them when ready. I guess the official route is to
> create
> > a feature enhancement request trac ticket with the files attached.
>
> Alright. I'll create a ticket when everything is ready. Since it's not
> getting in before at least 1.53, I'll take my time and do something good.
>

Sure, sounds good. Thanks,

- Jeff