Re: [boost] [iterator] why isn't there a mapped_type iterator adaptor in boost?

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]>  
wrote:

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

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

If so, can you explicitly and prominently declare that in the  
documentation?  The documentation here:  
http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/concepts/overview.html  
, 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  
the Introduction.)

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.

http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/concept_implementation/semantics/functions.html

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:

http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/utilities/iterator_range.html

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

See page:

http://www.boost.org/doc/libs/1_43_0/libs/range/doc/html/range/reference/adaptors/introduction.html

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

Thanks,

-Mostafa