Boost logo

Boost :

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
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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at