Re: [boost] New Iterator Adapters - filter_iterator

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-03 18:24:56

Thomas Witt <witt_at_[hidden]> writes:

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

In that case, in addition to asserting statically, shouldn't we use
enable_if to "turn off" the top-level functions?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com