> still I don't understand why declaring 'friend TClass' doesn't help. It's a
new YourClass()
is called not in TClass, but in special function generated by CINT.
Like:
void *G__YourClass_qwerty09987() {return new YourClass();}
(of course it is nor real CINT mangling)
Victor
Axel Naumann wrote:
>
> Hi,
>
> still I don't understand why declaring 'friend TClass' doesn't help. It's a
> limitation by rootcint, right? Or did I "infriendificate" the wrong class?
>
> Best regards, Axel.
>
> > -----Original Message-----
> > From: owner-roottalk@pcroot.cern.ch
> > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Victor Perevoztchikov
> > Sent: Tuesday, January 30, 2001 4:29 PM
> > To: gmieg@SLAC.stanford.edu
> > Cc: roottalk@pcroot.cern.ch
> > Subject: Re: [ROOT] Default constructor call in Streamer
> >
> >
> > > "Why does the def constr have to be public?"
> >
> > Default constructor is inevitable for reading class from file.
> > CINT generates some code to create the class by class name.
> >
> > > "For the time being: Is there a workaround?"
> >
> > There is no workaround. It is limitation, but I think,
> > very small limitation.
> >
> > Victor
> >
> >
> > George Irwin wrote:
> > >
> > > 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
> >
> > --
> > Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch
> > Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000
> > tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690
> >
> >
--
Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch
Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000
tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:35 MET