Re: TStrings (fwd)

Rutger van der Eijk (r36@nikhef.nl)
Tue, 25 Aug 1998 13:44:37 +0200 (MET DST)


Sorry if you recieve this mail twice. (I first posted it on the newsgroup,
but didn't realise it wasn't forwarded to roottalk. Fons asked be to
repost it.), Rutger

---------- 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.