"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4235B296.4050205@boost-consulting.com... | Thorsten Ottosen wrote: | | > | > there is one alternative which might make copy_range less needed too. | > We could put this into sub_range<T>: | > | > operator T() const | > { return T( begin(), end() ); } | > | > So if you really want range2container conversion, you must use a | > sub_range<string>: | > | > str = sub_range<std::string>( find_first(intput, "jello" ) ); | > | | | Eeek, no! Implicit conversions should be avoided. except when they shouldn't be (like in derived* to base*) :-) | But thinking of this | as a range conversion is the right way to go, IMO, except that it should | be called "range_cast" and it should be explicit. hm..I dunno, the cast stuff implies some kind of extra work to me. | I agree this functionality is useful, but this is a rather unfortunate | interface choice, in my opinion. For instance, what if I want to copy to | an array: | | int rg[3] = copy_range<int[3]>(aRange); // oops, can't return array if we had template< class T, class Range > T copy_to_seq( const Range& r ) { T t; t.assign(begin(r),end(r)); return t; } support of boost::array<T,size> could be ok. | All these problems are handled nicely by the std::copy algorithm, which | takes an output iterator as a parameter. A general, extensible | range-based algorithm library should take output /ranges/ as parameters, | or even just an output iterator, but this is all beside the point The iterator interface suffers from either being slow or being unsafe, so I don't think that is the way to go either. |. A | range-based copy algorithm should have a different interface and be part | of a complete range-based algorithms library. yes, agreed. We just need somebody to write those special range algorithms. -Thorsten