Re: [ROOT] private TCollection copy ctor?

From: Rene Brun (Rene.Brun@cern.ch)
Date: Fri Sep 01 2000 - 15:18:55 MEST


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