On Sat, Oct 13, 2012 at 4:25 PM, Louis Dionne <louis.dionne92@gmail.com>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