Hi Marco,
Marco van Leeuwen wrote:
>
>
> I am having a feeling that I encounter related problems. In my case, an
> interpreted class causes a segmentatioon violation at gROOT->Reset() (the
> destruction of the object).
>
> I really do not quite understand why closing a TFile should delete the
> "associated" objects, especially when they are object instances on 'stack'
> (which were automatically created by the compiler/interpreter), such as in
> the situation the above mail refers to. I think this obscures the control
> of the programmer over the lifetime of her/his objects and up till now I
> haven't encountered a situation in which this was handy. Could someone
> explain this?
>
I have already answered this point. My recommendation is;
-use objects in the local scope if these are just temporary objects
that
you want to be automatically deleted when you leave the scope.
-always use new when you create objects to be drawn, made persistent,
etc.
> ----------
>
> Furthermore, I was wondering about the something associated for drawn
> objects. I've been rereading the ROOT-documentation ("Overview") and I
> found the follwing, on page 35 How to Draw Objects:
>
> An instruction Object->Draw() in fact does not draw directly. It simply
> adds a reference (...) This means that if the content of object changes,
> your picture will change.
>
> This is not true, at least not for "stack" based TH1F and TF1. (I didn't
> check how it exactly works with heap based ones.) Does this have to do with
> the fact that stack based object might suddenly leave scope and therefore
> you don't want to have a canvas reference to them?
yes, see above. It is fundamental to understand the scoping rules of
C++.
>In my code, this means
> that I often Draw and object more than once. Does this mean that copies are
> created, or is there some "intelligence" in the Draw function which deletes
> the old version? And: is there another way to make the re-Painting happen
> (simply c1.Update() seems to be inadequate). I would also like to know
> whether the desctruction of a drawn object is a potential seg-vio action.
> If so, it might be a good idea to add a Object->Undraw() or something like it.
Every time you call Draw, a new reference is added to the list of
primitives
in the current pad. For important objects, such as histograms, TH1::Draw
clears the pad (unless you specify the contrary with the option "same").
If you have modified a list of objects, you do not need to call Draw
again
for these objects, just call TPad::Modified() and the repainting will be
automatic.
If you delete an object in a pad, the reference to this object is
automatically
deleted, precisely to avoid a double delete.
How do we do this.
All objects than can be drawn derive from TObject.
When you do
object->Draw();
the bit kIsInCanvas is set in the data member fBits of TObject.
when you do
delete object;
the TObject destructor is automatically invoked by your object
destructor.
The TObject destructor checks if the bit kIsInCanvas is set. If yes, it
scans
all canvases/pads to see if there is a reference to this object. If yes,
the reference to the object is deleted from the list of primitives and
you should
see the object physically removed from the canvas(es).
Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:39 MET