Hi,
I am still a bit worried about these changes to previously defined globals
like gPad and gDirectory. The trick (i.e. gPad as a #define to some
global function) applied now seems not to work. Even if I access the
global function directly I have problems. As mentioned before the macro:
{
// create pad
if (!Pad()) {
if (!gROOT->GetMakeDefCanvas()) return;
(gROOT->GetMakeDefCanvas())();
}
Pad()->Clear();
}
crashes on v2.23/12 with:
root [0] .x PadTest.C
Error: illegal pointer to class object Pad() 0x0 218
FILE:/afs/cern.ch/user/r/rutger/mycmt/ot/RootTest/v5/macros/PadTest.C
LINE:7
*** Interpreter error recovered ***
So, or I'm doing something wrong or the mechanism doesn't work.
This is my primary problem at the moment, and I need a solution NOW!
On the long term. I partly agree with what was mentioned by Fons and
Alexander. I think using a static member function is the best place to put
these global entry points. In there you can decide to do something
different in case of threads or other things. 2 comments:
1) I would suggest the name of these statics to be something like:
TVirtualPad::current()
because that is what they actually are, a pointer to the currently
selected pad/directory. TVirtualPad::Pad() doesn't say anything. The only
reason to call it Pad() is because the historical gPad.
2) The short cut gPad. As it seems now gPad in CINT is only known after
something is drawn. Fons suggest to use Pad() directly in that case. I
think this is confusing. Or you/we use gPad or Pad() (or
TVirtualPad::Pad() later). Writing a macro I shouldn't depend on the fact
if another macro has already drawn something or not. So somehow gPad
should always be known to CINT. If this is not possible I suggest to
dissuade people from using gPad, and also change all the standard ROOT
examples/macros to use the static member function directly.
cheers,
Rutger
> Hi, just a comment.
>
> Probably it would be good to extent "root naming rules"
> for these static functions, e.g.
>
> TDirectory::Dir() will be TDirectory::gDir()
> TFile::File() -> TFile::gFile()
>
> TMath::SomeConstant() -> TMath::kSomeConstant()
>
>
> Best regards. Valery
>
>
> Hi Alexander,
>
> you are right and of course I thought about putting the globals
> (gPad, fFile, gDirectory) as static member of their respective classes.
> First I thought about typing economics, typing Pad() at the command line
> instead of TVirtualPad::Pad() makes a difference. However, thanks to a
> later deviced CINT "trick" I can still allow users to type gPad and
> so now there is no econimics reason anymore I will make them static
> methods.
>
> Cheers, Fons.
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:20 MET