A
Andy Lomax
I'm deriving from a base class in a library, and the library vendor is
expecting me to add a 'string&' member in my derived class. Or, to be
more precise, they have provided two virtual functions:
1 void setstr(const std::string& str)
2 std::string& getstr(void)
So my obvious implementation is:
class foo : vendor_bar {
string& str;
public:
virtual void setstr(const string& str_) { str = str_; }
virtual string& getstr(void) { return str; }
};
I've got a bad feeling about this. Is it a good idea to have a
reference member like this? I can't think of any specific problems,
but I'd rather use a smart pointer of some sort.
Another factor is that the string is actually originally provided by
me (the library user), isn't used elsewhere in the library, and simply
comes back to me in the 'setstr' call; I use it myself further down in
the hierarchy. Given this, is there some better way that the library
could have been designed, rather than hard-wiring in a string
implementation?
Cheers
AL
expecting me to add a 'string&' member in my derived class. Or, to be
more precise, they have provided two virtual functions:
1 void setstr(const std::string& str)
2 std::string& getstr(void)
So my obvious implementation is:
class foo : vendor_bar {
string& str;
public:
virtual void setstr(const string& str_) { str = str_; }
virtual string& getstr(void) { return str; }
};
I've got a bad feeling about this. Is it a good idea to have a
reference member like this? I can't think of any specific problems,
but I'd rather use a smart pointer of some sort.
Another factor is that the string is actually originally provided by
me (the library user), isn't used elsewhere in the library, and simply
comes back to me in the 'setstr' call; I use it myself further down in
the hierarchy. Given this, is there some better way that the library
could have been designed, rather than hard-wiring in a string
implementation?
Cheers
AL