Hi, there are two "promised" but - as of 3.01/00 - not yet implemented changes I've found. Could you please add the changes at some point? * TTree::SetBranchStatus("SomeBranch") will not set SomeBranch consistently if SomeBranch holds a TClonesArray (see http://root.cern.ch/root/roottalk/roottalk00/3180.html) * friend access macro for ClassDef / protected std c'tor not yet available (see attached email conversation) Okay, and here's the bug: For some reason the 3.01/00 version requests VISUAL_CPLUSPLUS to be defined, _WIN32 or WIN32 is not good enough to get ANSICPP defined (see RConfig.h). Thus using MSVC6 (which does not define VISUAL_CPLUSPLUS) I end up with _QUOTE_(whatever) being evaluated to char* "name" - which is very confusing... Cheers, Axel. ---- this is the attached email conversation... Hello George, As far as cint's concern, the feature has already been implemented while ago. I am not sure about changes required in rootcint, if there is any. Could you elaborate what is missing? Thank you Masaharu Goto >Date: Tue, 13 Mar 2001 18:20:55 -0800 >From: George Irwin <gmieg@EGNEXT1.SLAC.STANFORD.EDU> >Reply-To: gmieg@SLAC.Stanford.EDU >To: rootdev@pcroot.cern.ch >Cc: axel@fnal.gov >Subject: Re: rootcint globals & standard construc > >Hi ROOT team, I was hoping to find this change in ROOT 3.00/06, >but my protected default constructors still don't work with >ROOT I/O. Is this change still in the works? I hope so. >Thanks. George > >Begin forwarded message: > >Date: Mon, 05 Feb 2001 20:04:51 +0900 >From: Masaharu Goto <MXJ02154@nifty.ne.jp> >Subject: RE: rootcint globals & standard construc >To: axel@fnal.gov, rootdev@pcroot.cern.ch >Cc: gmieg@EGNEXT1.SLAC.STANFORD.EDU > >Hello Alex, Rene and Fons, > >I've been working to allow private constructor access in >order to enable ROOT streamer. I implemented an experimental >code in cint5.14.74 which I will copy next week. > > >One change is needed on ROOT file. Please refer to the attached > >Rtypes.h. You need to add a macro ProtectedAccess(name) in a > >couple of location. This change should be harmless for current >version. So, you can make this change immediately. > >Rootcint will create a new file [dictfile]P.h >This file is an automatically created friend declaration >for private member access. The macro is called within >modified ClassDef() macro. > > > $ rootcint -f mydict.cxx -c user.h LinkDef.h > >>>> mydictP.h is created > >And user header must include this as follows > > // user.h > #ifndef __MAKECINT__ // must be enclosed by this > #include "mydictP.h" > #endif > class A : public TObject { > private: > A(); > > ClassDef(A,1); // macro PrivateAccess(A) is called inside > }; > >And new pragma link statement has to be added in LinkDef.h > > // LinkDef.h > #pragma link C++ class+private A; > > >Please test this next week when I'll copy 5.14.74. > >Masaharu Goto > > > >>Date: Sat, 3 Feb 2001 12:13:23 -0600 >>From: "Axel Naumann" <a.naumann@worldnet.att.net> >>Reply-To: <axel@fnal.gov> >>To: "Masaharu Goto" <MXJ02154@nifty.ne.jp> >>Cc: <gmieg@EGNEXT1.SLAC.STANFORD.EDU> >>Subject: RE: rootcint globals & standard constructor >> >>Dear Masaharu, >> >>this is a fantastic idea! Yes, and you got me exactly right, this is >exactly >>the problem we are struggeling with. Okay, I will try to add a macro >>definition and I will tell you what it looks like and how it works. >Thanks a >>lot! >> >>Best regards, >>Axel. >> >>> -----Original Message----- >>> From: Masaharu Goto [mailto:MXJ02154@nifty.ne.jp] >>> Sent: Saturday, February 03, 2001 8:46 AM >>> To: axel@fnal.gov >>> Cc: gmieg@EGNEXT1.SLAC.STANFORD.EDU >>> Subject: RE:rootcint globals & standard constructor >>> >>> >>> Hello Alex, >>> >>> Thank you for your idea. This is quite logical and sounds very >>> interesting. >>> Yes, this issue belongs to CINT. >>> >>> As I understand your needs .. >>> >>> 1) You have a class with private constructor which needs to be >>> instantiated >>> in limited situation. This is achieved by friend declaration. >>> 2) You want to use ROOT streamer. For doing so, ROOT needs to >>> call the prvate >>> construction which is not possible now. >>> 3) You want to allow ROOT streamer to use private constructor, >>> but want to >>> keep privacy for other usage. >>> >>> Am I correct? >>> >>> Unfortunately, the wrapper functions has to be global and >declaraing >>> TCINT as a friend class will not help either. >>> >>> - Wrapper functions has to be global because it's pointer has to >>> be registered >>> into Cint dictionary which is exported from DLL. If it is a >>> member function >>> , >>> Cint needs to deal with a generic pointer to member function. >>> Such definitio >>> n >>> does not exist in C++. Maybe there is a way to workaround but >>> it is not >>> simple anyway, cheating compiler in some sense. >>> - The wrapper functions are generated by rootcint. So, name of the >wrapper >>> function is not determined until rootcint is used. If you expect >TCINT >>> class to have a fixed definition, we can not include the >>> wrapper functions >>> as member of TCINT. >>> >>> If this is really important, a better way would be to automate >friend >>> declaration so you don't need to do it manually. For example, we >>> could add >>> a macro in ClassDef, such as >>> >>> #define ClassDef(name,x) \ >>> . >>> PrivateAccess(name) >>> >>> And in the dictinoary, rootcint generates code like this. >>> >>> #define PrivateAccess(name) PrivateAccess_##name >>> #define PrivateAccess_MyClass1 >\ >>> friend int G__MyClass1_MyClass1_0_0(.......); \ >>> friend int G__MyClass1_PrivateFunc_0_1(.......); >>> >>> This way, no change is needed to user code. >>> There are a couple of technical issues. More investigation is >needed. >>> >>> Thank you >>> Masaharu Goto >>> >>> >Dear Masaharu, >>> > >>> >maybe you have heard that some people were discussing the >>> limitation to have >>> >_public_ standard constructors to be able to use the dictionary >wrapped >>> >classes with e.g. ROOT streamers, TTrees etc. The problem arises >when one >>> >wants to restrict the ability of the user of a library to >construct new >>> >objects - for that one must be able to declare the c'stor >>> private. We have >>> >learnt that the actual "new MyObj()" call is wrapped into a >>> global function, >>> >called G__MyObj_N_M, where N and M are numbers, as generated by >>> rootcint. So >>> >of course one can define the std c'stor as private and add all >the global >>> >functions as friends. But this is a) very time consuming and b) >>> very hard to >>> >read & understand. Now of course it would be much much nicer to >>> have all the >>> >globals wrapped into one class (e.g. a singleton), so one could >>> simply add >>> >e.g. "friend TCINT" (maybe even in the ClassDef macro). >>> > >>> >I know this would be a horrible work: A lot of work and a very >annoying >>> >work. I would volunteer to help, but of course the first >>> question is: Why do >>> >the globals have to be global? And: Did I guess right that this >>> belongs to >>> >the CINT rather than in the ROOT division? >>> > >>> >Thanks for your help. >>> > >>> >Best regards, >>> >Axel
This archive was generated by hypermail 2b29 : Fri Jun 08 2001 - 11:51:24 MEST