RE: [Boost-Users] Fw: [boost] Iterator Adaptor Poll

From: Hickman, Greg (greg.hickman_at_[hidden])
Date: 2002-07-26 07:36:43

> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
> Sent: Thursday, July 25, 2002 4:00 PM
> To: Boost-Users_at_[hidden]
> Subject: [Boost-Users] Fw: [boost] Iterator Adaptor Poll
> 
> 
> Hi Everyone,
> 
> Have you tried to use iterator adaptors and found the documentation
> wanting? I have recently updated the documentation in the CVS:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boos
> t/boost/libs/
> utility/iterator_adaptors.htm?rev=HEAD
> 
> However, enough people have had problems approaching this 
> library that I
> thought it would be useful to ask about what would make a gentle
> introductory example. Beman recently sent me the enclosed, 
> but it seems to
> define such an oddball toy iterator that I'm not sure it 
> would be a very
> good motivating example. I'm asking for input, especially 
> from anyone who
> has "gotten over the hump" so to speak, with iterator adaptors.

I'm brand new to iterator_adaptors, and this is probably way too trivial an
example, but I have several classes in my project which aggregate other
polymorphic objects in part-whole relationships.  I'd like clients who call
'the_aggregate.begin()' to be able to call non-const methods on the
aggregate's Parts, but I'd like to prevent direct replacement of the
underlying container element 'Part*' itself.  Likewise, I'd like clients who
call 'the_aggregate.begin() const' to be prevented from doing anything with
the aggregate's Parts other than calling it's const methods.  Of course, the
STL container-supplied iterators aren't intended to work in this way.

If this situation is common enough, and iterator_adaptor can be used to
quickly generate iterators with the desired behavior (I haven't completely
tested it as of yet, but it seems to work), then perhaps this is just one
example of a reasonable "Hello, world" introduction to iterator_adaptors.

Greg