Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-12-05 05:54:33


brangdon_at_[hidden] wrote:

> 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().

This is not directly related. It is good if such algortihm return something
more usable than std::pair, but I see no connection to the way of passing
containers/sequences to algorithms.

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

Do you imply possible inefficiencies? This is not problem, I guess. Algorithm
taking Sequence should not assume it can be copied in O(1). If it needs to
create range with Sequence interface, it should do so explicitly:
template<class Sequence>
void something(const Sequence& s)
{
        boost::range<typename Sequence::iterator> r(boost::next(s.begin()), s.end());
        // .....
}

> - Inelegance of algorithms having to use iterators in addition to
> sequences if they want to do anything more than pass the sequence
> on.

Not sure I get you. What is wrong with using iterators to denote elements in
sequence. For example std::vector::insert takes iterator, and I don't see
nothing wrong with 'middle' parameter passed to std::rotate.
(http://www.sgi.com/tech/stl/rotate.html)

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

It depends... actually my original proposal
(http://groups.yahoo.com/group/boost/message/15179)
was to make algorithms work 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?

No. It returns something that has begin() and end(). It supposedly uses lazy
evaluation to get next value. For example, see VTL:
http://www.zib.de/weiser/vtl/

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

Does your observation still hold for case of special kind of container
returned?

> I think we will always need some glue in some cases, where legacy code
> needs to be adapted.

"Legacy code"? I think that function returning something with begin() and
end() should be used much more actively. This is not legacy code at all, IMO.

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

And
        filter(v, some_predicate)
is even less verbose. If this is workable, which is my hypothesis, why don't
use this approach?

> > ? 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 :-)

OK.

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

Interesting! Have to admit that this is the less painfull approach I've seen
so far.

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk