"Eric Niebler" <eric@boost-consulting.com> wrote in message news:4270F421.8040806@boost-consulting.com... | Thorsten Ottosen wrote: | > "Eric Niebler" <eric@boost-consulting.com> wrote in message | > news:4270186E.20907@boost-consulting.com... | > | > | I should also point out that FOREACH is ready and useful today, whereas | > | range_ex has major outstanding design questions. | > | > which are those btw? | > | > -Thorsten | > | | | Documented here: http://tinyurl.com/957z9, but in short: | | * Output ranges or output iterators? We have eg. template<class InIt, class OutIt> OutIt copy(InIt first, InIt last, OutIt dest); template<typename Rng, typename OutIter> OutIter copy(Rng const &, OutIter); Should the latter then take an OutputRange (whatever that means)? I guess that is not a bad idea; Let's say an out-put Range defines this function: template< class I > iterator insert( I beg, I end ); Then we could define copy() like this: template< class InputRng, class OutputRng > typename range_iterator<OutputRng>::type copy( const InputRng& in, OuputRng out ) { out.insert( begin(in), end(in) ); } Then we could call copy() it like this: list<int> in; vector<int> out; copy( in, range_back_inserter(out) ); list<int> in; int array[] = { ... }; copy( in, range_overwriter( array ) ); always safe and fast. Alternatively, we could introduce a new function in the output iterator a. la. insert() above; then we could define a tag and require algorithms to dispatch to different implementation of the algos. This might not seem like too clever. | * For algos that take 2 sequences, take 2 ranges or a range and an iterator? Like in template<typename Rng1, typename Rng2> BOOST_DEDUCED_TYPENAME boost::range_iterator< Rng1 >::type search(Rng1 &, Rng2 const &); ? What use would it be to only have an iterator? | * Should find(map) call map.find()? no IMO. The algorithms are different in complexity. | * When using the range algos to copy chars, do we try to ensure | null-termination? As I see it, we just have to pick one default and stick with that. Boost.Range does not include the null in the length of the string; I think that is acceptable. Perhaps a special adapter that automatically searches for a null and/or includes it in the range can be provided: copy( null_string_range( a_string ), ... ); -Thorsten