"inheriting" constructors

[Christof Warlich]

Hi,

I'd like to define a class that should behave as much as posible
like std::string, but that has some small additional property:

class ExtendedString: public std::string {
public:
void someExtendedFun ctionality(void ) {}
};

As new classes do not inherit the constructors from its base, is
it true that I would have to define counterparts for all std::string
constructors that I may want to use to construct my derived class?

class ExtendedString: public std::string {
public:
void someExtendedFun ctionality(void ) {}
ExtendedString( const char *data): std::string(dat a) {}
ExtendedString( const std::string &data): std::string(dat a) {}
ExtendedString( void): std::string() {}
// ......
};

Or is there some smarter way to tell the compiler that the constructors
of std::string may be used right away, saving all the typing effort?

Thanks for any tips,

Christof

[Kai-Uwe Bux]

Re: "inheritin g" constructors

Christof Warlich wrote:

Hi,
>
I'd like to define a class that should behave as much as posible
like std::string, but that has some small additional property:
>
class ExtendedString: public std::string {
public:
void someExtendedFun ctionality(void ) {}
};
>
As new classes do not inherit the constructors from its base, is
it true that I would have to define counterparts for all std::string
constructors that I may want to use to construct my derived class?
>
class ExtendedString: public std::string {
public:
void someExtendedFun ctionality(void ) {}
ExtendedString( const char *data): std::string(dat a) {}
ExtendedString( const std::string &data): std::string(dat a) {}
ExtendedString( void): std::string() {}
// ......
};
>
Or is there some smarter way to tell the compiler that the constructors
of std::string may be used right away, saving all the typing effort?

a) You can use templated constructors:

ExtendedString( ) : std::string() {}

template < typename A >
ExtendedString( A a ) : std::string( a ) {}

With std::string, I think you need to go up to 4 arguments.


b) It appears that your ExtendedString has no additional data members and
that the functionality provided by

void someExtendedFun ctionality(void ) {}

could as well be provided by a free-standing function. If so, a
free-standing functions is probably more appropriate. Maybe, you can even
come up with a generic implementation working on character-ranges. In that
case, you would have a more flexible addition to your library with less
code.


c) Many people frown upon public derivation from container classes. In my
opinion, it's not a deadly sin; but you should be aware of the possible
pitfalls:

1) Keep in mind that the destructor of std::string is non-virtual.

2) Note that functions like

std::string some_func( std::string const & str );

will happily accept ExtendedString objects as arguments, but they
will return std::string output. There are situations, where this
can get tricky.


Best

Kai-Uwe Bux

[Christof Warlich]

Re: &quot;inheritin g&quot; constructors

Kai-Uwe Bux schrieb:

a) You can use templated constructors:
>
ExtendedString( ) : std::string() {}
>
template < typename A >
ExtendedString( A a ) : std::string( a ) {}
>
With std::string, I think you need to go up to 4 arguments.

Thanks, that was the type of idea I was looking for. Although
it's a pity that it still needs one definition for each number
of parameters that shall be supported ...

c) Many people frown upon public derivation from container classes. In my
opinion, it's not a deadly sin; but you should be aware of the possible
pitfalls:
>
1) Keep in mind that the destructor of std::string is non-virtual.
>
2) Note that functions like
>
std::string some_func( std::string const & str );
>
will happily accept ExtendedString objects as arguments, but they
will return std::string output. There are situations, where this
can get tricky.

But even more thanks for pointing out the pitfalls!