[LC++]Re: [Tuxcpprogramming] Not everything inherited with inheritance??
Mark Phillips
mark at austrics.com.au
Fri Jul 20 11:54:48 UTC 2001
Jack Lloyd wrote:
> No. Specifically, constructor are not passed on by default, you have to
> call them yourself.
Okay. Thanks for this. Is it only the constructors which are not
passed on?
I changed my example to the following:
class tstTy: public string {
public:
void printIt() {
cout<<*this<<endl;
}
tstTy(char const* cStr): string(cStr) {}
};
And now it seems to work okay. Is there anything else I
should add?
> > Why is this so???
>
> Because you did not provide an operator=, the compiler used the default
> definition of one, which:
>
> 1) converts it's argument to the appropriate class (tstTy in this case)
>
> 2) does a copy of each element of the first object to the other one
>
> The problem being there is now way to convert a const char* into a tstTy
> in (1). So the compiler gives up.
>
> > And what can I do about it?
>
> Create a constructor to handle the conversion from a const char* to a
> string.
>
I thought conversion was handled by something like
operator char*() const {......}
rather than via the constructor???
Does C++ use constructor argument for conversion as well??
> BTW, are you sure you want to be doing this? STL containers (including
> string) are not really meant for derivation.
What I want is basically a string with extra functionality. In particular
I want it to have an extra member function associated with it called
"getToken(string& str)" which will extract tokens from the string,
tokens being separated by whitespace.
Because what I want _is_ actually a string --- ie I want to be able to do
everything else you can do with a string --- it makes sense (I thought)
to derive it from "string". The only difference is that it has this extra
functionality.
Is my reasoning faulty here? Is there a better way of doing what I
want?
Thanks for your help,
Mark.
More information about the tuxCPProgramming
mailing list