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. Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
