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

From: Axel Naumann (axel@fnal.gov)
Date: Thu May 10 2001 - 00:14:03 MEST


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