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

Subject: Re: [boost] [iterator] [property_map] Enhancement proposals
From: Louis Dionne (louis.dionne92_at_[hidden])
Date: 2012-10-13 19:25:51

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);

with [Iterator = Third]
     [WrappedIter = Third] (because Second::WrappedIter == Third)

By the same mechanism, Second is convertible to First. Now, let's see why we
can construct a First from a Third:

    Third third;
    First first(third); // This calls the template unary constructor below.

    First(Third const& iterator,
          typename enable_if_convertible<Third, Second>::type* =0)
        : out_(iterator) // This calls the template unary constructor below.
    { }

    Second(Third const& iterator,
           typename enable_if_convertible<Third, Third>::type* = 0)
        : out_(iterator) // This calls the constructor of Third, which is
    { }                  // std::back_insert_iterator.

I hope my explanation is clear enough. There is also a unit test for this on
the master branch.

> If you had the following chained_output_iterator constructor:
>
> template< class G, class J >
> chained_output_iterator(chained_output_iterator<G,J>,
>   typename enable_if_c< mpl::and<
>     is_convertible<H,G>,
>     is_convertible<J,I>
>   >::value >::type * = 0);
>
> Oops, now chained_output_iterator< F, derived_t * > is convertible to
> chained_output_iterator< F, base_t * >. is_convertible<J,I> is too loose
> (admittedly, there are many iterator contexts where you simply cannot
> prevent the derived_t * -> base_t * conversion, but if you can prevent it,
> you should).
>
> Presently, there is no such converting constructor, and I don't yet see a
> need for one.

Thanks for the explanation. I replaced the loose copy constructor by the one
generated by the compiler.

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

Thanks!

Louis Dionne