Hi Valeri, okay, but that can't be a reason. When linking against Root I get errors because in my non-CERN, non Fortran project there is no VISUAL_CPLUSPLUS. I do understand that it's defined in some config for the compilation of Root itself - but that doesn't help me writing my own programs which include Rconfig.h (via any Root header) and don't understand the _NAMEn_ macros etc and have ANSICPP, R__PLACEMENTDELETE etc #undef as VISUAL_CPLUSPLUS is #undef. I change that VISUAL_CPLUSPLUS to _MSC_VER in Rconfig.h et voila it works. I just think VISUAL_CPLUSPLUS is the wrong guy to ask in Rconfig.h... Cheers, Axel. > -----Original Message----- > From: owner-roottalk@pcroot.cern.ch > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Valeri Fine > Sent: Thursday, May 10, 2001 3:20 PM > To: Axel Naumann > Cc: Roottalk@Pcroot. Cern. Ch > Subject: Re: [ROOT] 3.01/00: Req for two changes + one bug for free > > > > > > Hi Fons, > > > > can't you #ifdef on _MSC_VER? It's defined for MSVisualC++, whereas > > VISUAL_CPLUSPLUS is not. > > > > Just to make things more clear VISUAL_CPLUSPLUS flag was introduced by > CFortran > package and adopted by CERNLIB to compile CERN Program library for > "Microsoft" > platform. > It is in use within ROOT to compile the various ROOT-Fortran application > interfaces > properly. > > Cheers, > Valeri > > > What about the two changes, the SetBranchStatus for > TClonesArrays and the > > protected std c'stor feature? > > > > Regards, Axel. > > > > > -----Original Message----- > > > From: owner-roottalk@pcroot.cern.ch > > > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Fons Rademakers > > > Sent: Thursday, May 10, 2001 3:26 AM > > > To: Axel Naumann > > > Cc: Roottalk@Pcroot. Cern. Ch > > > Subject: Re: [ROOT] 3.01/00: Req for two changes + one bug for free > > > > > > > > > Hi Axel, > > > > > > for Visual C++ you'll have to define -DVISUAL_CPLUSPLUS (which is > > > now defined in root-config --cflags (in the CVS version)). We > need this > > > for future support of other Windows compilers. > > > > > > Cheers, Fons. > > > > > > > > > On Wed, May 09, 2001 at 05:14:03PM -0500, Axel Naumann wrote: > > > > 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 > > > > > > -- > > > Org: CERN, European Laboratory for Particle Physics. > > > Mail: 1211 Geneve 23, Switzerland > > > E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248 > > > WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910 > > > > > > > > >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:45 MET