Hi George, TIter is a generic iterator for TCollection based containers. just in constructor it demands this collecion TIter(TCollection* col ..) It is impossible in C++ to make general polimorphic wrapper class for arbitrary collection. It is not a problem of ROOT. Victor George Heintzelman wrote: > > Rooters, > > I was recently looking at making a TIter wrapper of an STL iterator to > some set of root objects, which I thought would be a nice way of using > root's polymorphic iterators to mask implementation details. > Unfortunately, I discovered that this is a lot trickier than it (IMHO > at least) needs to be. TIterator is the polymorphic class, and I tried > simply deriving from TIterator, but I discovered that TIterator demands > a GetCollection function to return the TCollection the iterator points > to. Well, fine, I thought, there is no TCollection, so 0 is a valid > return there. > > But then I realized that this is an essential part of TIterator/TIter, > since TIter calls GetCollection and then a virtual operator= (which is > also bizarre, and quite possibly rather less than type-safe, but I > digress) in order to copy itself. I should say 'create a new iterator > in what is probably the same way I did the other one' rather than copy, > though. > > So in order to create this wrapper, I also have to create a new > TCollection class, with all the baggage that that demands (at a > minimum, I have to create unusable Add, Clear, Delete, and Remove > functions, along with a working MakeIterator returning one of my > iterator class) for a class that I hope will never be used (I could of > course be interested in creating a ROOT wrapper around an STL container > separately, but lets assume that I don't want to deal with Streamer > issues and all the other root machinery for right now). > > Why doesn't TIter simply demand a valid Clone() or similar function > from TIterator? That would be easy for implementers of derived classes > to implement. In addition to easily allowing the use of Root-style > iterators with STL containers, it would let you build TIterator classes > which filter through the output of another TIterator to select > particular objects from a collection (without building a new collection > with the needed objects first), concatenate containers, and so forth. > This is the kind of flexibility I would want to have in return for > paying the (IMHO fairly high) price of virtual function calls and VFT > pointers in iterator classes. > > Finally, I doubt that TIterator's GetCollection and operator= functions > are being used outside TIter's implementation, so eliminating this > functionality and replacing it with Clone() will not hurt anyone. I > could be wrong about this, of course, but I would think that if you > needed the actual collection you would just pass the collection rather > than a TIterator to it. > > George -- Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000 tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:30 MET