Hi Rene, Apart from the issue of a special constructor with
TBuffer argument, I'm curious about the answers to Axel's other
questions:
"Why does the def constr have to be public?"
"For the time being: Is there a workaround?"
Thanks. George
> 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