Hi Axel,
TTree::SetBranchStatus should work as announced in 3.01.
In case you have a branch TClonesArray (eg fTracks),
tree.SetBranchStatus("fTracks*",0); sets the status for all sub branches
tree.SetBranchStatus("fTracks",1); activates the branch count only
In general, tree.SetBranchStatus("xxx*",0) deactivates all branches with
a name starting with "xxx".
I assume that Fons will process your other points.
Rene Brun
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
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:45 MET