|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-01 08:41:53
Okay, I understand what you're getting at here.
Should cursor() be renamed as_sequence()?
Does the documentation need a warning about the dangers of modifying the
container during iteration?
-Dave
----- Original Message -----
From: "Ullrich Koethe" <koethe_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, December 01, 2000 6:10 AM
Subject: Re: [boost] py_cpp and vector<..>::const_iterator
David,
yes, it would be more natural, but also less efficient if the original
C++ sequence didn't support random access. Suppose, l was
std::list<Foo>. Then
for x in l.cursor():
takes constant time per step (linear overall), while
for x in l:
takes linear time per step (quadratic overall). This difference occurs
because cursor remembers the last item retrieved (by way of its embedded
iterator), while list doesn't. This only reinforces Stepanov's great
insight that working with iterators leeds to more generic code than
working with data structures.
For C++ containers that support indexing (including std::map, hash_map),
we could provide automatic wrapping into the more natural interface.
However, I don't see an urgent enough need for this feature to implement
it now.
Regards
Ulli
David Abrahams wrote:
>
> Ullrich,
>
> the cursor stuff looks good, but it leaves me wondering why your interface
> provides:
>
> y = l.cursor()[3]
> for x in l.cursor():
>
> but not:
>
> y = l[3]
> for x in l:
>
> which would seem more natural.
>
-- ________________________________________________________________ | | | Ullrich Koethe Universität Hamburg / University of Hamburg | | FB Informatik / Dept. of Computer Science | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe_at_[hidden] Germany | | koethe_at_[hidden] | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk