---------- Forwarded message ----------
Date: Tue, 25 Aug 1998 13:15:34 +0200
From: Rene Brun <Rene.Brun@cern.ch>
To: r36@nikhef.nl
Cc: Rene Brun <Rene.Brun@cern.ch>
Subject: Re: TStrings
Hi Rutger,
I fully agree with all your comments about casting. That is why
we made the changes of the argument types in our latest version.
My comment about casting was a recipee for a temporary solution.
Rene Brun
Rutger van der Eijk wrote:
>
> Hi ROOTers,
>
> Something which bothers me already for some time got triggered by a
> remark Rene makes.
>
> Rene Brun wrote:
>
> Wouter Hulsbergen wrote:
> >
> > Dear developpers,
> >
> > Two questions:
> > A. For some reason it was decided that every TH1 object
> must have a
> > unique name. Why ? It is quite inconvenient, as one always
> needs to
> > make up a new name, even when a histogram exists only
> temproary.
> > B. All TH1 constructors have `Text_t*' arguments for name
> and title.
> > Unfortunately TString.Data() returns a `const char*'.
> Consequently, I
> > cannot use a TString for name and title, unless I first
> copy it into a
> > non-const char*. (At least, this is so for TProfile). Why
> not replace all
> > `Text_t*' in TH1 with `const Text_t*'? (Or by TStrings..!)
>
> >
>
> By default TH1, TProfile and TTree objects are inserted by
> their
> constructors in the list of objects in memory associated to
> the
> current directory/file. When the objects are introduced in
> the list,
> a check is made for a unique name in the list.
> This feature allows in an interactive session to draw an
> histogram
> by name (CINT automatically creates a pointer with the same
> name).
> You can disable this feature if after having created the
> object,
> you set his directory pointer to 0. Example
> TH1F *h1 = new TH1F("h1",...
> h1->SetDirectory(0);
>
> In the version coming this week (2.00/11), we have already
> cleaned most
> calls including Text_t and Option_t. The complete list of
> changes
> is included in the version news.
>
> Concerning your problem with TString.Data(), you can always
> cast
> the parameter to a char*.
>
> Of course it is always possible to cast an object (i..e explicit type
> conversion). However, in my opinion, the use of casting signals an
> 'ill formed' or at most C-style program. B. Stroustrup, 3th edition
> says: "If you feel tempted to use an explicit type conversion, take
> time to consider if it is really necessay. In C++, explicit type
> conversion is unnecessary in most cases when C needs it and also in
> many cases in which earlier versions of C++ needed it. In many
> programs explicit type conversion can be completely avoided; in
> others, its use can be localised to a few routines." (6.2.7 page
> 130) In the ROOT classes casting is often used, in most cases to
> retrieve run-time information of TObject derived classes. If this is
> combined with TObject::Inheritsfrom(...) a save conversion can be
> guaranteed. This seems to me a legitimate way of using casting. In
> case of a conversion from const to non-const you somehow bypass the
> compiler type checking because the routines you use don't provide/ask
> you with the right 'type' (i.e. const or not). This is definitly not a
> save way of using casting. In simple cases, like above, this is not a
> to big problem. The programmer knows he does an 'unsave' conversion,
> but might also know that the TH1 constructor does not modify the
> Text_t*, i.e. that it SHOULD have constant in it's declaration!
> This all might sound a bit academic. I agree that the quickest
> solution in cases as above is to just use casting. But as this is a
> consequence of 'ill-formed programming' (sorry I use this expression
> so often, but I always have to laugh when the aCC compiler tells me
> the this if a did something 'dirty'.) I don't agree to advise people
> to use it 'just like that'. After all casting is something we should
> be avoided in C++.
> Finally I would like to mention that C-style casting is used (i.e.
> (T) e) instead of the C++ explicit type conversion operators
> static_cast, reinterpret_cast, const_cast and dynamic_cast. The
> difference are mainly with respect to portability of code (some of the
> different C++ cast operators ensure portability). On the other hand it
> might be that these operators are not defined for the older compilers
> jet. Which again raises questions about the portability of the ROOT
> code itself.
>
> Rene Brun
>
> The above statements are not intended to be agressive, and surely
> not to question the usefullness of the ROOT classes.
>
> Cheers,
>
> Rutger van der Eijk.