> 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