Re: Dynamically choosing what to "new" (Aside)
"James Kanze" <james.kanze@gmail.com> wrote in message
news:1181424432.858079.283710@p77g2000hsh.googlegroups.com...
On Jun 9, 12:22 pm, Pat <n...@none.none> wrote:
All the derived classes are required to implement this method and return
the appropriate string, for example:
void Dog::GetName(std::string *s)
{
*s = "Dog";
}
"Not related to your problem, but is there any reason for passing
a poniter to a string, and not simply returning a string."
Or better still, a reference so null-checking can be eliminated.
But, my preference is that "get functions" return what they are getting, and
not prepending "get" to the function name, and Name() seems better as a base
class non-virtual function:
const char* Animal::Name()
{
return name; // ptr to a char array containing "Dog"
}
or (for those who prefer "fat C++" over "veneer C++" style coding):
// note that reference return allows this function to be used as a setter
also
// if it wasn't const but in this case of usage setting is not appropriate
for the
// data member which will be initialized at construction somehow.
//
const std::string& Animal::Name()
{
return name; // ptr to a string containing "Dog"
}
I don't see any reason to hide-away "Dog" as a string literal in one of the
methods (does anyone else?). It's data, so why make it "code-like"?
(LOL, I was just going to post about preferably passing in references rather
than pointers, and then I started thinking a bit about the actual context
and design).
John