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