Thomas Witt <[EMAIL PROTECTED]> writes: > Dave, > > On Thursday 03 July 2003 09:32, David Abrahams wrote: >> Thomas Witt <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost