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