STL string inheritance

[Mike Tyka]

Hello community,

i'm fairly new to using the STL but i've been experimenting a bit with it.
I tried to derive a new class say MyString from string like so:

class MyString: public string{
public:
MyString(){}
};

when i then try to do:

MyString MyStringInstance;
MyStringInstance = "BlaBlaBla";

it moans:
error C2679: binary '=' : no operator found which takes a right-hand operand
of type 'const char [9]' (or there is no acceptable conversion)

MyStringInstance += "BlaBlaBla";

and

string MyStringInstance;
MyStringInstance = "BlaBlaBla";

works fine though.

Why is the = operator not available in MyString ??

Thanks for any help, Mike :)

P.S. I'm using MS Visual C++ .NET

[Fabio]

"Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk...

Hello community,

i'm fairly new to using the STL but i've been experimenting a bit with it.
I tried to derive a new class say MyString from string like so:

class MyString: public string{
public:
MyString(){}
};

when i then try to do:

MyString MyStringInstance;
MyStringInstance = "BlaBlaBla";

it moans:
error C2679: binary '=' : no operator found which takes a right-hand operand of type 'const char [9]' (or there is no acceptable conversion)

MyStringInstance += "BlaBlaBla";

and

string MyStringInstance;
MyStringInstance = "BlaBlaBla";

works fine though.

Why is the = operator not available in MyString ??

Thanks for any help, Mike :)

P.S. I'm using MS Visual C++ .NET

operator=() is not directly inherited by the derived class, it is the
standard C++ behaviour (IMHO)

Fabio

[Peter Koch Larsen]

"Fabio" <fa*************@libero.it> skrev i en meddelelse
news:2s*************@uni-berlin.de...

"Mike Tyka" <m.****@gnx.net> wrote in message

news:I4********@bath.ac.uk...

Hello community,

i'm fairly new to using the STL but i've been experimenting a bit with it. I tried to derive a new class say MyString from string like so:

class MyString: public string{
public:
MyString(){}
};

when i then try to do:

MyString MyStringInstance;
MyStringInstance = "BlaBlaBla";

it moans:
error C2679: binary '=' : no operator found which takes a right-hand

operand

of type 'const char [9]' (or there is no acceptable conversion)

MyStringInstance += "BlaBlaBla";

and

string MyStringInstance;
MyStringInstance = "BlaBlaBla";

works fine though.

Why is the = operator not available in MyString ??

Thanks for any help, Mike :)

P.S. I'm using MS Visual C++ .NET

operator=() is not directly inherited by the derived class, it is the
standard C++ behaviour (IMHO)

Fabio

Rubbish! Of course it is.
/Peter

[Rob Williscroft]

Peter Koch Larsen wrote in news:K7f7d.54262$Vf.2607123
@news000.worldonline.dk in comp.lang.c++:

operator=() is not directly inherited by the derived class, it is the
standard C++ behaviour (IMHO)

Fabio

Rubbish! Of course it is.

Not so, Fabio is correct (*), operator = if not declared by the user
is generated by the compiler (uses member/base-wise assignment),
hence the compiler generated operator = hides the base class
operator =.

*) This depends on the interpretation of "directly inherited"
of course :).

The easiest way to declare operator = is:

#include <iostream>
#include <string>

class MyString: public std::string
{
public:

MyString(){}

using std::string::operator =;
};

Alas this won't work for constructors.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[David Hilsee]

"Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk...

Hello community,

i'm fairly new to using the STL but i've been experimenting a bit with it.
I tried to derive a new class say MyString from string like so:

class MyString: public string{
public:
MyString(){}
};

<snip>

I always feel the urge to say this, so I'm saying it. First tip about the
standard container classes: they were not designed for inheritance. The
container classes have no virtual member functions (even the important
destructor) and no standard protected members. If MyString is just going to
hold a bunch of utility functions for std::string, then just use non-member
functions (possibly in a namespace) instead.

--
David Hilsee

[Karthik Kumar]

David Hilsee wrote:

"Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk...

Hello community,

i'm fairly new to using the STL but i've been experimenting a bit with it.
I tried to derive a new class say MyString from string like so:

class MyString: public string{
public:
MyString(){}
};

<snip>

I always feel the urge to say this, so I'm saying it. First tip about the
standard container classes: they were not designed for inheritance. The
container classes have no virtual member functions (even the important
destructor) and no standard protected members. If MyString is just going to
hold a bunch of utility functions for std::string, then just use non-member
functions (possibly in a namespace) instead.

Or you could think of 'aggregation' relationships a.k.a member
relationships.

class MyString {
public:

MyString(const string & ref) : str(ref);
// Methods that operate on the member variable 'str'.
// ......................

private:

string str;
};

--
Karthik.
http://akktech.blogspot.com .

[Peter Koch Larsen]

"Rob Williscroft" <rt*@freenet.co.uk> skrev i en meddelelse
news:Xn**********************************@130.133. 1.4...

Peter Koch Larsen wrote in news:K7f7d.54262$Vf.2607123
@news000.worldonline.dk in comp.lang.c++:

operator=() is not directly inherited by the derived class, it is the
standard C++ behaviour (IMHO)

Fabio

Rubbish! Of course it is.

Not so, Fabio is correct (*), operator = if not declared by the user
is generated by the compiler (uses member/base-wise assignment),
hence the compiler generated operator = hides the base class
operator =.

*) This depends on the interpretation of "directly inherited"
of course :).

I believe we are in agreement here. To sum it up: operator= behaves exactly
like any other member function or operator, but since the compiler generates
its own operator= you can not use it without some trickery.

/Peter

[snip]

[Gavin Deane]

Karthik Kumar <ka*******************@yahoo.com> wrote in message news:<415e46b5$1@darkstar>...

David Hilsee wrote:

"Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk...

Hello community,

i'm fairly new to using the STL but i've been experimenting a bit with it.
I tried to derive a new class say MyString from string like so:

class MyString: public string{
public:
MyString(){}
};

<snip>

I always feel the urge to say this, so I'm saying it. First tip about the
standard container classes: they were not designed for inheritance. The
container classes have no virtual member functions (even the important
destructor) and no standard protected members. If MyString is just going to
hold a bunch of utility functions for std::string, then just use non-member
functions (possibly in a namespace) instead.

Or you could think of 'aggregation' relationships a.k.a member
relationships.

class MyString {
public:

MyString(const string & ref) : str(ref);
// Methods that operate on the member variable 'str'.
// ......................

private:

string str;
};

Then you have to explicitly forward any parts of std::string's
interface that you want MyString to have. If you want a restricted
interface (like the standard sequence adapters) this might be the
right solution.

But if you want all the functionality of a std container plus some
more of your own, and your OO design[*] calls for a new type to
provide this functionality, then inheriting from the container might
be the simplest solution.

The only thing you absolutely MUST not do is delete the derived
objects polymorphically because the base class doesn't have a virtual
destructor. But as long as you understand that, then there's no
problem. As a practical matter, you won't be able to do anything
polymorphically because the std containers don't have any virtual
functions. But in this case polymorphism isn't the goal - a new class
with the container's functionality plus more of your own is.
[*] I'm assuming that if you're considering inheritance, you're
thinking OO.

GJD

[David Hilsee]

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

Karthik Kumar <ka*******************@yahoo.com> wrote in message news:<415e46b5$1@darkstar>...

David Hilsee wrote:

"Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk...
>Hello community,
>
>i'm fairly new to using the STL but i've been experimenting a bit with it.>I tried to derive a new class say MyString from string like so:
>
>class MyString: public string{
> public:
> MyString(){}
>};

<snip>

I always feel the urge to say this, so I'm saying it. First tip about the standard container classes: they were not designed for inheritance. The container classes have no virtual member functions (even the important
destructor) and no standard protected members. If MyString is just going to hold a bunch of utility functions for std::string, then just use non-member functions (possibly in a namespace) instead.

Or you could think of 'aggregation' relationships a.k.a member
relationships.

class MyString {
public:

MyString(const string & ref) : str(ref);
// Methods that operate on the member variable 'str'.
// ......................

private:

string str;
};

Then you have to explicitly forward any parts of std::string's
interface that you want MyString to have. If you want a restricted
interface (like the standard sequence adapters) this might be the
right solution.

But if you want all the functionality of a std container plus some
more of your own, and your OO design[*] calls for a new type to
provide this functionality, then inheriting from the container might
be the simplest solution.

I have not yet seen any "OO design" that irrefutably called for inheritance
from a standard container. If utility functions for std::string are
desired, they do not need to be written in a derived class. In fact, it is
better if they are not, because they are more easily reused in programs that
use std::string and not MyString. Most of the time, this is what is
desired. If the intention is to provide a string class that could later
have its std::string representation replaced, then the std::string should
probably be a private member.
The only thing you absolutely MUST not do is delete the derived
objects polymorphically because the base class doesn't have a virtual
destructor. But as long as you understand that, then there's no
problem. As a practical matter, you won't be able to do anything
polymorphically because the std containers don't have any virtual
functions. But in this case polymorphism isn't the goal - a new class
with the container's functionality plus more of your own is.

I'm not sure if that's best described as a goal or as a solution to a
problem, and a solution that usually has better alternatives at that.

If you honestly need a class that publicly exposes std::string's interface
and has more functionality thrown in, then I think the following is a little
more "honest":

class MyString {
public:
// constructors, etc
std::string s;
// additional stuff here
};

To access the string, simply write foo.s.blah() instead of foo.blah(). This
avoids forwarding functions at the cost of two extra keystrokes. It also
avoids the "delete pString" issue. Most people would say that it doesn't
feel right, but it's about the same as public inheritance from the
std::string.

--
David Hilsee

[Mike Tyka]

"David Hilsee" <da*************@yahoo.com> wrote in message
news:0a********************@comcast.com...

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

Karthik Kumar <ka*******************@yahoo.com> wrote in message news:<415e46b5$1@darkstar>...

David Hilsee wrote:
> "Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk... >
>>Hello community,
>>
>>i'm fairly new to using the STL but i've been experimenting a bit with it.

>>I tried to derive a new class say MyString from string like so:
>>
>>class MyString: public string{
>> public:
>> MyString(){}
>>};
>
> <snip>
>
> I always feel the urge to say this, so I'm saying it. First tip

about

the > standard container classes: they were not designed for inheritance. The > container classes have no virtual member functions (even the

important > destructor) and no standard protected members. If MyString is just

going to > hold a bunch of utility functions for std::string, then just use non-member > functions (possibly in a namespace) instead.
>
Or you could think of 'aggregation' relationships a.k.a member
relationships.

class MyString {
public:

MyString(const string & ref) : str(ref);
// Methods that operate on the member variable 'str'.
// ......................

private:

string str;
};

Then you have to explicitly forward any parts of std::string's
interface that you want MyString to have. If you want a restricted
interface (like the standard sequence adapters) this might be the
right solution.

But if you want all the functionality of a std container plus some
more of your own, and your OO design[*] calls for a new type to
provide this functionality, then inheriting from the container might
be the simplest solution.

I have not yet seen any "OO design" that irrefutably called for

inheritance from a standard container. If utility functions for std::string are
desired, they do not need to be written in a derived class. In fact, it is better if they are not, because they are more easily reused in programs that use std::string and not MyString. Most of the time, this is what is
desired. If the intention is to provide a string class that could later
have its std::string representation replaced, then the std::string should
probably be a private member.

The only thing you absolutely MUST not do is delete the derived
objects polymorphically because the base class doesn't have a virtual
destructor. But as long as you understand that, then there's no
problem. As a practical matter, you won't be able to do anything
polymorphically because the std containers don't have any virtual
functions. But in this case polymorphism isn't the goal - a new class
with the container's functionality plus more of your own is.
I'm not sure if that's best described as a goal or as a solution to a
problem, and a solution that usually has better alternatives at that.

If you honestly need a class that publicly exposes std::string's interface
and has more functionality thrown in, then I think the following is a

little more "honest":

class MyString {
public:
// constructors, etc
std::string s;
// additional stuff here
};

To access the string, simply write foo.s.blah() instead of foo.blah(). This avoids forwarding functions at the cost of two extra keystrokes. It also
avoids the "delete pString" issue. Most people would say that it doesn't
feel right, but it's about the same as public inheritance from the
std::string.

--
David Hilsee

Thanks a lot for all your answers, i think i'm slowly getting my head round
this stuff.. I kept the example generic for simplicity's sake.
I want to create a data structure and a correcponding mask data structure,
both of
which have all of the properties of a string, and it would be useful to have
all it's functionality
(like cutting, concatenating etc etc). At the same time both data structures
will want to have
additional functionality, specialised to the type of data they're holding,
but no more additional
data - so the lack of virtual destructors etc shouldnt matter !?Hence the
inherited approach seems
sensible in this case ?

Am i thinking along the right lines here ?

Mike :)

[David Hilsee]

"Mike Tyka" <m.****@gnx.net> wrote in message news:I5********@bath.ac.uk...
<snip>

Thanks a lot for all your answers, i think i'm slowly getting my head round this stuff.. I kept the example generic for simplicity's sake.
I want to create a data structure and a correcponding mask data structure,
both of
which have all of the properties of a string, and it would be useful to have all it's functionality
(like cutting, concatenating etc etc). At the same time both data structures will want to have
additional functionality, specialised to the type of data they're holding,
but no more additional
data - so the lack of virtual destructors etc shouldnt matter !?Hence the
inherited approach seems
sensible in this case ?

Am i thinking along the right lines here ?

Even if the derived class contains no additional data, it's still undefined
behavior if you pass delete a std::string pointer when it is a pointer to an
instance of the derived class. Of course, you can avoid doing that in your
programs, and it's hard to accidentally do it simply because std::string has
no virtual member functions.

I tend to gripe about public inheritance of standard containers because it
is using inheritance to expose an implementation detail as a "nameless
public member". Many people choose to do that instead of having a public
member because inheritance is generally considered "better" than public
members. Unfortunately, in this case, it's roughly the same thing. It's a
general problem when inheritance is used for code reuse purposes (discussed
in the FAQ a bit in the Smalltalk/C++ comparison -- 30.4). However, for
most smaller programs, it doesn't really matter.

--
David Hilsee

[Gavin Deane]

"David Hilsee" <da*************@yahoo.com> wrote in message news:<0a********************@comcast.com>...

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

Karthik Kumar <ka*******************@yahoo.com> wrote in message news:<415e46b5$1@darkstar>...

David Hilsee wrote:
> "Mike Tyka" <m.****@gnx.net> wrote in message news:I4********@bath.ac.uk...

<snip deriving MyString from std::string>

> I always feel the urge to say this, so I'm saying it. First tip about the > standard container classes: they were not designed for inheritance. The > container classes have no virtual member functions (even the important
> destructor) and no standard protected members. If MyString is just going to > hold a bunch of utility functions for std::string, then just use non-member > functions (possibly in a namespace) instead.
>
Or you could think of 'aggregation' relationships a.k.a member
relationships.

class MyString {
public:
MyString(const string & ref) : str(ref);
// Methods that operate on the member variable 'str'.
// ......................
private:
string str;
};

Then you have to explicitly forward any parts of std::string's
interface that you want MyString to have. If you want a restricted
interface (like the standard sequence adapters) this might be the
right solution.

But if you want all the functionality of a std container plus some
more of your own, and your OO design[*] calls for a new type to
provide this functionality, then inheriting from the container might
be the simplest solution.

I have not yet seen any "OO design" that irrefutably called for inheritance
from a standard container.

Very few design decisions are irrefutable. There are almost always
alternatives.

There is some blurring going on here between strings, where the OP
started, and the standard containers, which came up during the
discussion, and are much more general purpose than std::string.

I have never needed to create my own string type. Indeed I have
suffered in situations where too many different string types coexist.
But I have on a number of occasions wanted to add functionality to a
continer for a specific purpose.
If utility functions for std::string are
desired, they do not need to be written in a derived class. In fact, it is
better if they are not, because they are more easily reused in programs that
use std::string and not MyString. Most of the time, this is what is
desired.
Again, thinking containers rather than strings ...
I absolutely agree with that, but I'm not talking about utility
functions that could meaningfully apply to any container of the right
type.

As an example, I wrote a piece of software that communicated with some
electronics by reading and writing sequences of bytes over a serial
port. I wanted the messages in a std::vector<char> because I needed to
do vector-related things like iterating, push_backing etc. But I also
needed functionality very specific to my messages - parsing, building
up parts of the message from field specifier objects I had, for
example.

I could have done it all with free functions that took a vector<char>
and operated on it via its public interface only. But that seemed
wrong because it would make absolutley no sense to try and parse
something that happens to be a vector<char> but isn't one of my
messages.

What I really wanted was something like
typedef std::vector<char> my_message_type;
where typedef really does define a new and distinct type. But the
language doesn't provide that.
If the intention is to provide a string class that could later
have its std::string representation replaced, then the std::string should
probably be a private member.
Agreed. But that wasn't my intention either.

The only thing you absolutely MUST not do is delete the derived
objects polymorphically because the base class doesn't have a virtual
destructor. But as long as you understand that, then there's no
problem. As a practical matter, you won't be able to do anything
polymorphically because the std containers don't have any virtual
functions. But in this case polymorphism isn't the goal - a new class
with the container's functionality plus more of your own is.

I'm not sure if that's best described as a goal or as a solution to a
problem, and a solution that usually has better alternatives at that.

Well in the project I described above, the messages were the whole
point of the work. A type that could represent the messages was the
fundamental design goal.

In other similar situations I've tried alternatives and never come
across one that's as clean as inheritance.
If you honestly need a class that publicly exposes std::string's interface
and has more functionality thrown in, then I think the following is a little
more "honest":

class MyString {
public:
// constructors, etc
std::string s;
// additional stuff here
};

To access the string, simply write foo.s.blah() instead of foo.blah(). This
avoids forwarding functions at the cost of two extra keystrokes. It also
avoids the "delete pString" issue. Most people would say that it doesn't
feel right, but it's about the same as public inheritance from the
std::string.

I've never tried this idea, but to me personally it definitely doesn't
feel right, whereas inheritance does.

[David Hilsee]

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

"David Hilsee" <da*************@yahoo.com> wrote in message

news:<0a********************@comcast.com>...
<snip>

If utility functions for std::string are
desired, they do not need to be written in a derived class. In fact, it is better if they are not, because they are more easily reused in programs that use std::string and not MyString. Most of the time, this is what is
desired.

Again, thinking containers rather than strings ...
I absolutely agree with that, but I'm not talking about utility
functions that could meaningfully apply to any container of the right
type.

As an example, I wrote a piece of software that communicated with some
electronics by reading and writing sequences of bytes over a serial
port. I wanted the messages in a std::vector<char> because I needed to
do vector-related things like iterating, push_backing etc. But I also
needed functionality very specific to my messages - parsing, building
up parts of the message from field specifier objects I had, for
example.

I could have done it all with free functions that took a vector<char>
and operated on it via its public interface only. But that seemed
wrong because it would make absolutley no sense to try and parse
something that happens to be a vector<char> but isn't one of my
messages.

What I really wanted was something like
typedef std::vector<char> my_message_type;
where typedef really does define a new and distinct type. But the
language doesn't provide that.

I don't think the distinct type is necessary. The std::vector<char> base
would be publicly exposed for anyone to modify in any way they please. Its
contents could easily (and accidentally) be replaced with an arbitrary
sequence of characters that isn't one of your messages, and there's nothing
the derived class can do about that. The distinct type doesn't offer any
significant benefit that I can see. I'm not really sure what you mean by
"doesn't make sense". Maybe you meant "I'm never going to do that"? If
there is an invalid sequence of characters that "doesn't make sense" for
your messages, then I would revisit the private member solution.

<snip>

If you honestly need a class that publicly exposes std::string's interface and has more functionality thrown in, then I think the following is a little more "honest":

class MyString {
public:
// constructors, etc
std::string s;
// additional stuff here
};

To access the string, simply write foo.s.blah() instead of foo.blah(). This avoids forwarding functions at the cost of two extra keystrokes. It also avoids the "delete pString" issue. Most people would say that it doesn't feel right, but it's about the same as public inheritance from the
std::string.

I've never tried this idea, but to me personally it definitely doesn't
feel right, whereas inheritance does.

Many people would say that, and I think that might have something to do with
all of the "OO hype" that people hear from time to time. I'd argue that
they're about the same.

--
David Hilsee

[Gavin Deane]

"David Hilsee" <da*************@yahoo.com> wrote in message news:<3p********************@comcast.com>...

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

"David Hilsee" <da*************@yahoo.com> wrote in message news:<0a********************@comcast.com>...
<snip>

If utility functions for std::string are
desired, they do not need to be written in a derived class. In fact, it is better if they are not, because they are more easily reused in programs that use std::string and not MyString. Most of the time, this is what is
desired.

Again, thinking containers rather than strings ...
I absolutely agree with that, but I'm not talking about utility
functions that could meaningfully apply to any container of the right
type.

As an example, I wrote a piece of software that communicated with some
electronics by reading and writing sequences of bytes over a serial
port. I wanted the messages in a std::vector<char> because I needed to
do vector-related things like iterating, push_backing etc. But I also
needed functionality very specific to my messages - parsing, building
up parts of the message from field specifier objects I had, for
example.

I could have done it all with free functions that took a vector<char>
and operated on it via its public interface only. But that seemed
wrong because it would make absolutley no sense to try and parse
something that happens to be a vector<char> but isn't one of my
messages.

What I really wanted was something like
typedef std::vector<char> my_message_type;
where typedef really does define a new and distinct type. But the
language doesn't provide that.

I don't think the distinct type is necessary.

It makes the code more closely model the problem, making the intent
clearer.

some_return_type parse_message(const std::vector<char>& msg, ...) {
.... }

doesn't make sense where

some_return_type parse_message(const my_message_type& msg, ...) { ...
}

does because the function isn't for parsing a vector<char>, it's for
parsing a my_message_type. Again, my ideal solution would be a strong
typedef but we don't have those.
The std::vector<char> base
would be publicly exposed for anyone to modify in any way they please. Its
contents could easily (and accidentally) be replaced with an arbitrary
sequence of characters that isn't one of your messages, and there's nothing
the derived class can do about that.
The same risk exists with a public member or using a vector directly.
So here inheritance doesn't add anything, but it doesn't lose anything
either.
The distinct type doesn't offer any
significant benefit that I can see. I'm not really sure what you mean by
"doesn't make sense". Maybe you meant "I'm never going to do that"? If
there is an invalid sequence of characters that "doesn't make sense" for
your messages, then I would revisit the private member solution.

Whether the sequence of characters in the message object makes sense
has nothing to do with why I want a distinct type. There may (now or
in the future) be other vector<char> objects around that are used for
completely different things. It seems preferable to me to be able to
write a parse function that can only accept my messages (which may or
may not turn out to be full of garbage). Without a distinct type, I'd
be able to call the parse function for a vector<char> that wasn't a
message, which would make no more sense that calling it for an int.

<snip>

[Daniel T.]

"Mike Tyka" <m.****@gnx.net> wrote:

Thanks a lot for all your answers, i think i'm slowly getting my head round
this stuff.. I kept the example generic for simplicity's sake.
I want to create a data structure and a correcponding mask data structure,
both of
which have all of the properties of a string, and it would be useful to have
all it's functionality
(like cutting, concatenating etc etc). At the same time both data structures
will want to have
additional functionality, specialised to the type of data they're holding,
but no more additional
data - so the lack of virtual destructors etc shouldnt matter !?Hence the
inherited approach seems
sensible in this case ?
Is it the case that any sequence of characters that can be held in a
std::string, can also be held (and make sense) in one of your
specialized types?

If yes, then your specialized type isn't adding anything new, just use a
std::string. If no, then publicly inheriting from std::string is
dangerous because it exposes your type to misuse.

Either use private inheritance, or containment in the latter case.

Am i thinking along the right lines here ?

Ask yourself, "what are the invariants that exist for my specialized
type that are different than those that exist for std::string?" Then you
will be thinking along the right lines.

[David Hilsee]

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...
<snip>

Whether the sequence of characters in the message object makes sense
has nothing to do with why I want a distinct type. There may (now or
in the future) be other vector<char> objects around that are used for
completely different things. It seems preferable to me to be able to
write a parse function that can only accept my messages (which may or
may not turn out to be full of garbage). Without a distinct type, I'd
be able to call the parse function for a vector<char> that wasn't a
message, which would make no more sense that calling it for an int.

My point is that even with the new type, after a simple assignment, your
functions can be called for a std::vector<char> that wasn't a message. It
offers about as much protection as the typedef, so I didn't see any benefit
of a separate class over a typedef. It might guard against cases where the
programmer _accidentally_ passed your function the wrong std::vector<char>,
but I can't imagine that happening much, in practice. If your functions
work for any std::vector<char> (as they should, given the public
inheritance), then I'd just use a typedef to express the intent that it
should only be used for messages.

--
David Hilsee

[Markus Elfring]

> But if you want all the functionality of a std container plus some

more of your own, and your OO design[*] calls for a new type to
provide this functionality, then inheriting from the container might
be the simplest solution.

These templates are not designed so that they can be used as base
classes for polymorphism.
Their intended use is for value objects.
http://c2.com/cgi/wiki?ValueObject

[Markus Elfring]

> [...]

The only thing you absolutely MUST not do is delete the derived
objects polymorphically because the base class doesn't have a virtual
destructor. But as long as you understand that, then there's no
problem. As a practical matter, you won't be able to do anything
polymorphically because the std containers don't have any virtual
functions. [...]

Should the standard collections be treated as final classes like it
can be specified with a key word in Java?

[Gavin Deane]

Ma************@web.de (Markus Elfring) wrote in message news:<40**************************@posting.google. com>...

But if you want all the functionality of a std container plus some
more of your own, and your OO design[*] calls for a new type to
provide this functionality, then inheriting from the container might
be the simplest solution.

These templates are not designed so that they can be used as base
classes for polymorphism.
Their intended use is for value objects.
http://c2.com/cgi/wiki?ValueObject

Where do I mention polymorphism in the passage you quoted? If you read
the rest of the discussion you'll see that I wasn't talking about
using inheritance to get polymorhic behaviour at all.

In fact, in part my post that you snipped, I specifically said that
you wouldn't be able to use a classes derived from containers
polymorhically because containers have no virtual functions.

[Ron Natalie]

"Fabio" <fa*************@libero.it> wrote in message news:2s*************@uni-berlin.de...

operator=() is not directly inherited by the derived class, it is the
standard C++ behaviour (IMHO)

Standard behavior. The reason is simple. If you don't declare an operator=,
the compiler implicitly generates one for you. That hides any base class operator=.
Of course, if you do declare an operator=, it hides a base class operator=
so the effect is the same.