Re: [boost] New Iterator Adapters - filter_iterator

From: Thomas Witt (witt_at_[hidden])
Date: 2003-07-03 16:34:45

Dave,

On Thursday 03 July 2003 09:32, David Abrahams wrote:
> Thomas Witt <witt_at_[hidden]> writes:
> > I've checked in a fix for this. Static asserts make the instantiation of
> > iterator_adaptors members fail depending on the iterator category. You
> > may want to try it, though I don't have access to VC until tomorrow, so
> > it is not guaranteed to work.
>
> I guess with the new categories that might be OK.  With the old
> categories it was neccessary to allow operations which didn't
> correspond to the category so that users could build, e.g., random
> traversal readable rvalue iterators (had to be labeled as input
> iterator).  We should take care that we're not disallowing people from
> building useful iterators with capabilities that aren't accounted for
> by our categories.

The reason I choose to do it this way was that it was the least intrusive 
modification that did the job. I can envision a more sophisticated mix-in 
based approach but frankly I don't think that it's worth it.

As you said the problem of disallowing usefull combinations was mostly due to 
the old categories, but even with the old categories I would prefer the safe 
road. The user who wants to provide more than the category asks for can 
always reimplement the needed functions in a derived class. I like the idea 
of being explicit about doing something special. Furthermore I think that 
this inconvenience is more than outweighed by the added safety. Things that 
accidently compile should be avoided whereever possible.

Thomas

-- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de