[boost] Re: Formal Review: FOREACH macro

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-04-28 10:31:45

"Eric Niebler" <eric_at_[hidden]> wrote in message 
news:4270F421.8040806_at_boost-consulting.com...
| Thorsten Ottosen wrote:
| > "Eric Niebler" <eric_at_[hidden]> wrote in message
| > news:4270186E.20907_at_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