Re: Deriving a class from string

From:

"Daniel T." <daniel_t@earthlink.net>

Newsgroups:

comp.lang.c++

Date:

Sun, 05 Dec 2010 14:54:43 -0500

Message-ID:

<daniel_t-D9C611.14544305122010@70-3-168-216.pools.spcsdns.net>

On Dec 5, 9:39?am, Leigh Johnston <le...@i42.co.uk> wrote:

On 05/12/2010 14:35, Daniel T. wrote:

Sam<s...@email-scan.com> ?wrote:

Paulo da Silva writes:

I need a class with several string methods. I don't want to use the
string class itself because in future I may want to redefine it to
use other ways to implement the same (needed) methods but with a
different behaviour.

[snip]

What is the minimum code to have all string methods available in
myClass?

class myClass : public std::string {

};

Feel free to use myClass::substr(), myClass::begin(), myClass::end(), etc?
as expected.

Sam's idea of publicly deriving your class from std::string seems the
obvious answer, but I recommend against it. The std::string class was
not designed to be derived from and doing so could cause all kinds of
problems, some of which are hard to track down (e.g., object slicing.)

I suggest you use private inheritance instead of public. Implement the
constructors you need and export the minimum number of string functions
you need with using declarations.

class MyClass : private std::string
{
public:
? ? MyClass() { }
? ? explicit MyClass(const char* s): std::string(s) { }
? ? // and so on, only for the constructors you need

? ? // conversion operators made explicit to guard against
? ? // accidental object slicing and passing.
? ? explicit MyClass(std::string s): std::string(s) { }
? ? std::string std_string() const { return *this; }

? ? using std::string::operator[];
? ? using std::string::size;
? ? // and so on, only for the functions you actually need.
};

Then in the future, when you want to change the behavior of one of the
functions you exported, all you need to do is replace the using
declaration with your own code.

There is nothing wrong with publicly deriving from the standard
containers, see "Adjusting Interfaces" in "The C++ Programming
Language" (Stroustrup). ?See also the article I wrote on the subject
here: http://www.i42.co.uk/stuff/mutable_set.htm

Your article is excellent and gives several reasons why deriving from a
standard container is sometimes the wrong thing to do.

In this case, the OP explicitly said that he wants to be able to
redefine the behavior of one or more methods in unspecified ways.
Without knowing whether he intends to extend the invariant of his class
in ways that will break the is_a relationship, without knowing whether
he will be modifying the post-condition of some of the methods in such a
way as to make them incompatible with strings, without knowing if the
is_a relationship makes sense, and without knowing whether he wants to
be able to delete string objects that are actually objects of his class,
private inheritance is a better recommendation to make than public.

To put it another way, private inheritance will give Paulo more freedom
to let his class grow and change as it needs without forcing it to
continually conform to what strings must do. Whether or not he needs
such flexibility is not a call we can make but I thought it was
important to let him know of the limitations of public derivation, and I
thank you for pointing us to your article wich helps bring those
limitations to light.