> 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