bugSavannah Static web pages of project:
savroot

bugbugs #99577: -->Use TString rather than char* on ROOT functions/methods



Submitted by:  Andy Buckley <abuckley>
Submitted on:  2012-12-20 12:41
 
Bug / Feature:  * Suggestion Category:  Core libraries
Priority:  5 - Normal Severity:  2 - Minor
Status:  Clarified Privacy:  Public
Assigned to:  Open/Closed:  Closed
Release:  *AllDiscussion Lock:  Unlocked
Operating System:  * GNU/Linux
Summary:  *Use TString rather than char* on ROOT functions/methods
* Mandatory Fields

2013-02-04 21:39, comment #1:

Hi Andy,

I've added this suggestion to our task list for a future release (this or early next year).

Thanks for the suggestion.

Cheers, Fons.

Fons Rademakers <rdm>
2012-12-20 12:41, original submission:

I've heard many people (myself included!) gripe about having to call std::string::c_str() to use many core ROOT methods or types.
They could also construct a TString, but depending on the context this may be equally awkward. The fundamental issue is that many (all?) of the ROOT methods that use character string arguments and return types -- e.g. for filenames, for titles and labels, and for plotting options -- do so via the raw char* type rather than a string class.

Of course char* is discouraged in C++ programming because of the various ways that it allows you to screw up compared to std::string or TString. Both these can also be implicitly constructed from a supplied char* or string literal, so using const-refs to them for method arguments is pretty much a win-win situation: raw char*s and literals can still be used, but so can the more powerful/standard types.

I think the most natural improvement would be to replace the char* arguments and returns with TStrings -- that way the "native" ROOT string type is used, and implicit construction will happen from both char* and std::string. I see that TString already defines an implicit const char* cast operator, but changing the argument type would improve matters in the many situations where an std::string is received from non-ROOT code.

Thanks (and Merry Christmas)!

PS. The same issues of compatibility with idiomatic C++ and the STL come up wher raw C arrays (typically of numeric built-in types) are used in the ROOT API... but I think that's a separate and more complex situation, due to the templating, and because containers could be potentially big and hence could have significant performance implications that shouldn't be invoked implicitly. But strings in these methods are short, with no important CPU penalty in converting to/from char*, so this is purely a usability issue... albeit a common and significant one.

Andy Buckley <abuckley>



 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • Fons Rademakers <rdm> added by (rdm) (Posted a comment)
  • Axel Naumann <axel> added by (axel) (Updated the item)
  • Andy Buckley <abuckley> added by (abuckley) (Submitted the item)
  •  

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    2013-02-04 21:39rdmStatusNone=>Clarified
      Open/ClosedOpen=>Closed
      Closed on2013-02-04 21:39=>2013-02-04 21:39
    2012-12-21 15:54axelAssigned toNone=>rdm
    Show feedback again

    Back to the top