Subject: Re: [boost] [iterator] why isn't there a mapped_type iterator adaptor in boost?
From: Mostafa (mostafa_working_away_at_[hidden])
Date: 2010-05-15 22:59:12
On Sat, 15 May 2010 14:59:25 -0700, Neil Groves <neil_at_[hidden]>
> Indeed there were a number of
> older library designs that used runtime polymorphism with iterator
> hierarchies that ultimately discovered that this approach was vastly
> inferior to the generic iterator approach of the standard library.
> However I
> can certainly see that this is useful across module interface boundaries
> small collections etc.
I've found any_iterator to be indispensible in defining generic, decoupled
interfaces. Previously, I had to resort to writing my own GOF-like
runtime polymorphic iterators. As for cost, that's a matter of
perspective driven by business needs. For example, I've used
interface-level polymorphic-iterators with ~100k sized collections on
3-year old medium-priced desktops that ran under 3 seconds (if even that),
a result which was quite acceptable for the product's target audience.
Not that I don't appreciate your insights, I do, however for people
unfamiliar with this topic who may be reading this I think it would be
quite helpful to put into perspective the costs of using runtime
polymorphic iterators. Ultimately, it's up to the programmer to run their
own metrics and determine if it meshes with their business needs.
(Personal rant: another reason for this response is that too often I see
C++ programmers, especially the older crowd, sacrificing generic/decoupled
design out of cost concerns, without first putting into perspective what
those costs entail, ie, a) what is the range of the measured cost and b)
is it acceptable?)
> You can use the boost::iterator_range type and the
> boost::make_iterator_range function to help create a range from
I'm reading the Boost.Range documentation and I have a number of
questions/comments, listed below:
1) The documentation is a great reference. It's a frustrating as an
introduction. It's a frustrating as a tutorial. (Please don't take this
the wrong way, or personally.)
2) What exactly is the definition of Range? Is it any type that meets the
requirements of any one of the following concepts: Single Pass Range
Concept, Forward Range Concept, Bidirectional Range Concept, Random Access
If so, can you explicitly and prominently declare that in the
documentation? The documentation here:
, really beats around the bush. It describes some attributes of Range,
but doesn't quite define it.
Additionally, right next to this definition, can you give examples of some
common types which match the definition of Range? (Some are alluded to in
3) Why is the library named Range when it seems that only iterator_range
actually encompasses a range of iterators. Am I missing something here?
4) Having both range_iterator and iterator_range is just confusing. Are
you trying to purposefully make me dyslexic? ;)
5) Put "Notice that the above functions should always be called with
qualification (boost::) to prevent unintended Argument Dependent Lookup
(ADL)." prominently at the *top* of the following document, preferably
with some sort of advisory icon.
6) Same thing as 5) for the following comment "If an instance of
iterator_range is constructed by a client with two iterators, the client
must ensure that the two iterators delimit a valid closed-open range
[begin,end)." in the following page:
It's just too easy to miss these important preconditions if they're not
blatantly in your face.
7) The use of operator| is jarring. Especially in the introductory
examples without any textual introduction. (Yes, I did read the
motivation behind it, but it still doesn't jive with me. Maybe it's all
those years of math/cs indoctrination.) I think programmers won't freak
out as much if the introductory examples used function composition first
then showed the alternative with operator|.
> However for cases like these
> where you would like to have some syntactic sugar I would write this:
Finally, thanks for providing a usable any_range example. It's very
gracious of you.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk