Hi,
I noticed the following:
At 08:27 AM 9/8/99 +0000, you wrote:
>Hi Michael,
>Remove the statement output.Close() from your macro.
>Close delete all objects associated with the file, including
>your TProfile object. This object will again be deleted when leaving
>the scope of the function.
>The safe alternative is to always do
> TProfile *prof = new TProfile(...
>instead.
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?
----------
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? 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.
Thanks,
Marco van Leeuwen.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:39 MET