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