Date: 2001-12-04 17:53:12
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 ....
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.
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 :-)
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk