[ROOT] TMemberInspectors, ShowMembers, and class-type data members

From: George Heintzelman (gah@bnl.gov)
Date: Fri Jul 21 2000 - 17:33:53 MEST


Rooters,

We were trying to make use of the facilities of ShowMembers and our own 
derivation of a TMemberInspector class in order to make a generalized 
parameter-setting tool for certain of our class types, and we ran into 
a problem.

We wanted our classes to have TString's as data members, not char *'s, 
in order to not have to worry about the ownership of the strings 
ourselves -- let TString handle it, that's what it's supposed to do, 
right?

So we wrote classes like (barebones essentials shown, lots of other 
functionality of course):

TPhSomeModule: public TPhModule {
private:
  TString fInputDataName;	//& The '&' signals a parameter to our code.
}

and tried to use a general Set function on TPhModule:

TPhModule::Set(const Char_t * parametername, const TString &value);

where calling

TPhSomeModule x;
x.Set("fInputDataName","NewValue") 

would reset the value of the TString, using TString's operator=.

We used ShowMembers to help Set find the address of the thing it was 
supposed to change. This worked fine and dandy for Int_t parameters 
(which we had done a similar thing for), since those data member's 
address are put directly in the list. However, for TString data members 
(and presumably any other object types we might try in the future), we 
could only get the address's of *those object's* data members. In the 
case of the TString data member, we got the address of TString::fData. 
There's no way to go from the address to a pointer to Char to a pointer 
to the TString object holding that pointer (at least, not in anything 
resembling portable code).

So, is there any way around our problem, or any suggestions about how 
else to accomplish our task? We could I suppose force all our module 
writers to use Char_t * types instead, but that seems like an 
invitation to problems with ownership and painful code, and I had hoped 
that TString would avoid all that, so I'm looking for different 
suggestions. ;) The cleanest solution as far as I am concerned would be 
for the autogenerated ShowMembers to return the addresses of the 
objects themselves (instead of or in addition to) those object's data 
members, but I believe that that would entail a not-inconsiderable 
amount of work and tweaking on the part of the ROOT team...

George Heintzelman
gah@bnl.gov



This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:30 MET