Constructor to extend existing class

[JVene]

A few things occurred to me as a read through this thread.

I've had a number of encounters with the notion that a derived class may not require a virtual destructor, and experiment does seem to confirm this viewpoint on a great many compilers. There are a number of tempting arguments to promote the reasoning, but there are complications.

Like so many other arguments of this kind, the merits and demerits of goto being an example in a current thread of discussion hear, it's long winded, but not quite as controversial. The matter is eventually settled, and laserlight has the point. Even though it appears to work, it is specifically 'marked' as undefined behavior, and that alone should be sufficient to deter it as a practice. There are more, though, perhaps more convincing. There's little way to guarantee the class we create on this assumption retains that assumption when the code changes hands, even our own future hands should we forget or skip the documentation "beyond this place there be dragons". Someone might add data to the class, forgetting that it may not be destroyed appropriately.

Another point, almost as convincing, is what happens when the proposed derived class would be used as a parameter to a function expecting a string, either of a string *, string & or string by value. It's not so much what happens to slice off the derived class (if it has no data, where' not loosing much), but what if the purpose will eventually be to get it back.

In other words, do we not expect to get a string FROM something which we would hope to treat or use as this derived string object? If true (and we know it could be under a wide variety of circumstances), how? Insisting on placing the functional extension in a derived class actually causes a problem at this point.

Moving the functionality into a set of non-member functions steps aside these issues, and they have the potential to benefit a lot more of our code than the perception of namespace complications.

Laserlight has some good references on these points - objects (that somewhat vaguely defined term) need not be defined only by member functions, but a family of functions acting upon a concept - wherever those functions are placed. In particular, the point that we may obtain a string object from sources outside OUR code for which we want these new features I think is the paramount issue; as non-member functions their use is more widely usable in a situation like this (extending an existing library).

But a composition approach need not be all that bad. The class could accept a string as a reference upon construction and when required provide an automatic conversion to string so it could still be used as a string when required. When you consider that the new behaviors are likely to be needed only on occasion, this is likely a comfortable solution.