Re: [ROOT] Default constructor call in Streamer

From: Rene Brun (Rene.Brun@cern.ch)
Date: Tue Jan 30 2001 - 10:46:37 MET


Hi Axel,
There are several cases where Root has to create an object.
  - creation of a branch with an object
  - Input when Streaming in TBuffer::ReadObject
  - Object Inspection 
  - Creation of a context menu
  - html code generator

We try to eliminate as much as possible the calls to the default constructor
in the case of TTrees. But it would not be wise to have a special constructor
with a TBuffer argument, another one for inspection, etc.
In all the above cases, Root has to build a class dictionary to store
the member types and offsets in the class. This is done by calling
the object::ShowMembers function provided by the ClassDef macro.

Rene Brun

Axel Naumann wrote:
> 
> Hi,
> 
> I have the following problem: I want to protect a class's default
> constructor from the outside world (declare it as private, as no object of
> this type may be allocated). Even adding TClass as friend does not help (is
> that a rootcint parsing limitation or is the ::new actually called in some
> other class?).
> 
> Of course I would prefer a more general approach. One could ask: Why does
> the def constr has to be public? Actually the object is initialized by the
> Streamer's TBuffer. So in principle there should be a public:
> TMyObj::TMyObj(TBuffer&), which only calls the object's (e.g. private) def
> constr. It might look like an unnecessary overhead, but I think it makes
> sense: If you have a buffer to initialize my members you may use my
> constructor, otherwise: hands off. One could even add this constr to the
> ClassDef macro:
> 
> public: inline name::name(TBuffer&): name::name(){};
> 
> so the user would get a linker error not implementing the def const. I know
> this is not the "usual" implementation of streamers, most streamers
> explicitely require a public def constr. But I find this handier and
> cleaner. I don't really know what this would mean in terms of backwards
> compatibility, but it looks fine to me at first sight.
> 
> For the time being: Is there a workaround?
> 
> Best regards, Axel



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