> 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 Much more usual case, when user used TList as a member of class. Then compiler immediately complains about copy constructor of TList. If it would be TList copy constructor, then, invisible for user collections of objects will be copied. For pointer copy it will be soon reservation violation due to double delete, and memory leak for object copy Victor 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 -- 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:32 MET