Hi George, Hi Victor, I think that you are both right. George's request to copy only the pointers part of a collection without copying the objects is perfectly legitimate and should be supported. As Victor says, doing this via the copy constructor is extremely dangerous and with many side-effects. What about having a new function in TCollection and derived classes, say TCollection::ClonePointers to do the job in the same way that we already have the Clone function for any type of TObject? Rene Brun George Heintzelman wrote: > > > Do more people have an opinion on this subject? > > I guess I expressed myself already, but let me point out why I think > Victor's opinion is mistaken: > > > > I think the current implementation of copy constructor in TCollection > > > is correct. Only user can decide what does he want in copy. > > > Copy only pointers or copy objects. User can always inherit his collection > > > from TObjArray or TList and implement his own copy constructor. > > The TCollection documentation explicitly states that TCollections do > not own the objects in them, and that Delete() is just provided as a > convenience. Presumably if you implemented an owning collection you > could override this behavior, or if you copy a collection and also want > to copy its contents (say in a copy constructor for an object who owns > both a collection and its contents) you can do this. Furthermore, we > already have something which does a deep copy -- it's called Clone(). > (In this case returning a pointer-to-be-deleted is not so bad, since it > must be clear that the caller of Clone on a collection is now > responsible for the correct deletion of all the new sub-objects that > have also been created -- I would prefer an auto_ptr to make it 100% > clear, but auto_ptr is still not uniformly supported by compilers). > Choosing between Clone() and a copy constructor is the right place for > the user to make his decision about which version of the copy he wants. > > The current status means that if I want to copy just the pointers in a > collection, I have to first create a new class, then build an object of > the new class from the old class (which I presumably got from somewhere > else), then copy the instance of that new class out. > > > > Eight now, if user accidentally trying to copy collection, he has > > > error in linkig and aware, that he must do the decision. > > > And it is good. > > The only times you will 'accidentally' copy a collection is when > someone mistakenly enters a pass-by-value argument where they meant > pass-by-reference. This is a potential problem for any large class, not > just collections (and collections are smaller than some things, like > big TArrays, that CAN be passed by value). This should be fixed by user > training, documentation, and catching real problem instances by > profiling -- not preventing legitimate uses of the functionality. > > Anyway, that's the last I'll say on the matter, I think. > > George Heintzelman > gah@bnl.gov
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:32 MET