> About your other point in TTree::Draw, the current algorithm
> assumes that all your chain of pointers is valid and there is
> no protection in case a pointer is null. This requires some
> work in the query mechanism.
Actually TTree::Draw does NOT assume that the pointer has non-null
and it does proctect against them (hopefully :)).
However some user code (including one skeletton sent by Axel) using
TRef does NOT protect against a missing TRef'ed object.
The return value of TRef::GetObject is NOT guaranteed to be valid.
In particular if the object it not loaded is explicitly going to be a
nill pointer. Hence you should in most case write something like:
class B: public TObject{
public:
Int_t somemethod(){
AcualType * obj = dynamic_cast<ActualType*>(myA.GetObject()); // could
also be a simple C cast.
if (obj) return obj->somemethod();
else return 0; // or some other error code
}
private:
TRef myA; // ref to an A
};
-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Rene Brun
Sent: Tuesday, October 08, 2002 2:22 PM
To: Mathieu Ribordy
Cc: roottalk@cern.ch
Subject: Re: [ROOT] indirect use of TRef with TChain
Hi Mathieu,
The default behaviour of TRef cannot execute "load on demand".
TRef assumes that, you as a user, will load the corresponding data.
Once data is loaded, TRef knows how to set up the link to the data.
There is an option in TRef (load on demand) where you can
specify in the comment field of the TRef, the action to be
executed (call to a function, call to a CINT script, etc).
We show a minimum example of this process in the Event.h
example in $ROOTSYS/test (GetWebHistogram).
We are currently discussing extensions of this mechanism,
the TLongRef class. I will discuss this during a presentation
at the ROOT workshop next week.
About your other point in TTree::Draw, the current algorithm
assumes that all your chain of pointers is valid and there is
no protection in case a pointer is null. This requires some
work in the query mechanism.
Rene Brun
On Tue, 8 Oct 2002, Mathieu Ribordy wrote:
> Hi,
>
> I got a problem when dealing with chains and indirect references:
>
> a TFile has
> - a one entry tree, the detector
> - a tree with events, connected to the detector via a TRef
>
> when I use only one TFile, the reference to the detector is correctly
> set, after having used once the detector tree (I guess loading the
> detector into the memory sets the TRef). Then I can use event methods
> using the detector info (same with an event and a detector chain set
> from only one file, it works)
>
> Now I want to use a TChain, with multiple files. It works well when I
> use event methods not referring indirectly to the detector:
> ev->Draw("event.hits.GetOM().GetCoo().Z()"); // to draw the z-coo of the
> hits
>
> but it fails in this case (seg viol because of nil ptr), where a loop on
> hits calling hit->GetOM() is performed in Q():
> ev->Draw("event.tracks[10].Q()");
>
> because, unfortunately, the reference of the hits to the detector is
> hit->GetOM() = NULL. So it crashes.
>
> Question: why are the reference of the hits to the detector modules
> correctly set, but not for the track (it is not automatic). The
> references should be set automatically, as the full event is retrieved
> in mem.
>
> Maybe the right question is: how do I force the Draw method to retrieve
> not only the full event but also the references, when indirect ?
>
> Any help ?
> thanks a lot
> Mathieu
>
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:14 MET