Re: [boost] Re: iterator ranges; eliminating private member functions

From: brangdon_at_[hidden]
Date: 2001-12-04 17:53:12

In-Reply-To: <E16BCEO-0002aX-00_at_[hidden]>
On Tue, 4 Dec 2001 12:51:16 +0300 Vladimir Prus (ghost_at_[hidden]) wrote:
> Open issue indeed. Can we formulate our positions afresh?
> 1. vectors (strictly speaking, models of Sequence) are passed to 
> containers without any extra verbosity:
>   + Aleksey reports positive experience with this approach, supposedly  
>       meaning simplicity (Aleksey?). I'd agree.
>   - Problem with mutating algorithms

 - Problems with algorithms that need to return sequences as results.
   For example, std::equal_range(), my fat_partition().

 - Problems with algorithms that want to construct new sequences, or
   copy existing ones, internally, such as my fat_qsort().

 - Inelegance of algorithms having to use iterators in addition to
   sequences if they want to do anything more than pass the sequence
   on.
  
I have a general unease that a proposal that was originally just supposed 
to encapsulate a pair of iterators, has been mixed up with something else 
entirely, namely algorithms that act on containers.

> 2. special classes used for sequences:
>   + No problem with mutating algorithms
>   - Problems mixing with existing code & extra verbosity. Suppose I use 
> some view library. Then, I'd have to write something like .... 
>       max_element(seq::make_seq(filter(seq::make_seq(v),
> some_predicate)))

I don't understand. What is the result of filter? Does it return a 
std::pair?

I agree there are situations where containers are what is needed. If 
filter() actually wants to copy all the items, returning a vector fits 
exactly and Aleksey's approach wins. However, if filter() returns a 
std::pair, then as I understand it Aleksey would also need some verbose 
conversion code. Is there any reason to prefer one kind of example over 
the other? How many vector-returning algorithms are there in the current 
std library? How many pair-returning ones?

I think we will always need some glue in some cases, where legacy code 
needs to be adapted. There are some standard ways to ease the pain, such 
as using-declarations and wrapper classes/functions. We can surely write a 
simple inline wrapper for filter() that applies the make_seq 
automatically, if necessary.

It's worth comparing with how we would write it today, without sequences.

        filter(seq::make_seq(v), some_predicate);

is less verbose than:

        filter(v.begin(), v.end() some_predicate);

and the difference is greater if you use a meaningful name instead of "v". 
Unpacking a std::pair or a std::vector makes the difference even greater.

>    ? You previously talked about better support for sentinel values with
>     sequence objects, but I still don't think this is very important.

I agree there are more fundamental issues to resolve first :-)

> Actually, 
>         sort( seq::make_seq(v) );
> should work due to argument-dependent lookup.

Oh, good. For user-defined or boost containers, and even, in the fullness 
of time, std containers, we can add sequence accessors. Eg:

        sort( v.seq() );

avoids the explicit namespace entirely. I am beginning to see these 
verbosity issues as transient.

Dave Harris