Re: [ROOT] Problem with TFolder in a split TTree

From: Rene Brun (Rene.Brun@cern.ch)
Date: Fri Jan 12 2001 - 15:35:19 MET


Hi Dave,
I have added a protection in TLeafObject::FillBasket in case a branch
is a pointer to an abstract class that cannot be instantiated.

Note that classes such as TFolder cannot be used in split mode with the
current implementation of the Trees. As I already reported a few times,
I want to extend the Tree split machinery to revove the current restrictions.

Rene Brun

Dave Casper wrote:
> 
>         Hi,
> 
> I have a class which includes a data member of type TFolder.  I am trying to
> write this class to a TTree.
> 
> When I set the split level to anything other than 0 (i.e., 1 or 2) when
> making the TTree, I get the message:
> 
> Error in <TClass::New>: no default ctor for class TCollection
> 
> The program runs, but it is impossible to read the result (I get the same
> error message when I call GetEntry on the TTree, and value returned from
> GetEntry is not a pointer to an object of my class, but apparently a pointer
> to a TClass object).
> 
> I believe this error is happening because TFolder has a data member of type
> TCollection*.  TCollection is an abstract base class, and there is no
> default constructor for it.
> 
> With all the run-time type information available, is there some reason it
> should be impossible to write a pointer to an ABC to a TTree in this way?
> 
> I tried changing TCollection to make the default constructor public instead
> of protected, but I still get the above message.  Apparently it is not the
> accessibility of the constructor but rather the fact that one cannot create
> a TCollection object explicitly which triggers the problem.  TClass::New
> attempts to explicitly create an object of the type in question, and prints
> the error message if the result is NULL.
> 
> Strangely, if I do not split the TTree, there is no problem with writing my
> class (including its TFolder data member).  This makes me think the ABC is
> not an intrinsic limitation, but merely something not foreseen in the
> present implementation of Root (and therefore perhaps fixable).  I would
> think when reading the TCollection* from the file, it could create a
> concrete object of whatever subclass of TCollection is actually in the file,
> and then return a pointer to it (as TCollection*).
> 
> Thanks for any advice,
> 
> Dave
> dcasper@uci.edu



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:33 MET