Re: TStrings (fwd)

From: Rutger van der Eijk (r36@nikhef.nl)
Date: Tue Aug 25 1998 - 13:44:37 MEST


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.



This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:36 MET