Re: [ROOT] private TCollection copy ctor?

From: George Heintzelman (gah@bnl.gov)
Date: Thu Aug 31 2000 - 18:35:59 MEST


> 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