[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