Andre Poenitz wrote:
> Note that if this is done one of the main remaining reasons to stick to
> 'STRCONV' and --with-included-strings (namely smaller binaries) might go
> away, so this in fact could lead to nicer code.
This is what two people had to say on the matter on comp.lang.c++
In a nutshell: don't if you're going to use pointers to std::string.
I guess this is enough for Lars to say NOOOOOOOOOOOOOOOOOOO!
;-)
Angus
Responder #1:
===========================================================================
> That said, is there any real reason why I can't derive an otherwise
> empty String class from std::string? Will there be any hidden I
> surprises? As understand it, the fact that String has no member
> variables of its own means that the non-virtual std::string
> destructor is not an issue.
What makes you think it's not an issue? It is undefined behavior to
delete a derived object from a pointer to its base class without a
virtual distructor. It doesn't matter that the derived destructor
doesn't do anything or that there are no data members in the
derived class.
===========================================================================
and Responder #2
===========================================================================
> Hello,
>
> Could someone explain to me why the Standard conveners chose to typedef
> std::string rather than derive it from std::basic_string<char, ...>?
>
> The result of course is that it is effectively impossible to forward declare
> std::string. (Yes I am aware that some libraries have a string_fwd.h header,
> but this is not portable.)
>
> That said, is there any real reason why I can't derive an otherwise empty
> String class from std::string?
There are two issues.
(a) No virtual destructor. This means you can't safely call delete on
a pointer to string when the object pointed to is in fact a
derived_from_string.
(b) It isn't designed for polymorphism. (Like most of the standard
library.) Public inheritance is usually used for
polymorphism. Note (a) is a symptom of (b) .
If you somehow know you'll never use the derived_from_string
polymorphically, you won't encounter problems.
However, before proceeding, try private inheritance combined with a
few well-placed using statements. That is safer.
> Will there be any hidden surprises?
See above. Further, if people can make polymorphic use of your
derived_from_string type, they all too often will.
> As I understand it, the fact that String has no member variables of
> its own means that the non-virtual std::string destructor is not an
> issue.
[snip]
This has nothing to do with it. Calling delete on a pointer to string
is undefined behavior if it in fact points to a
derived_from_string, regardless of whether derived_from_string has
member variables of its own.
