RE: [ROOT] 3.01/00: Req for two changes + one bug for free

From: Axel Naumann (axel@fnal.gov)
Date: Thu May 10 2001 - 22:42:15 MEST


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