Re: LoadString overwrite
On Mon, 11 Sep 2006 23:14:04 +0100, "David Webber"
"Joseph M. Newcomer" <email@example.com> wrote in message
Because CString is now a template class, additional complexity is present.
I'm not deeply
into the subtleties of templates (I tend to use fairly simple template
classes), but I
think the notion of subclassing the CString template is far into the weird
I have never had any difficulties in deriving from template classes. In
fact I very often do things like
class MyElementArray : public std::vector<MyElement>
as well as deriving from my own template classes. I have never found any
weirdness, (but I haven't tried to maipulate them via virtual methods form a
base class pointer - I have never seen a need).
Virtual functions work fine in templates. Inheriting from a template full
specialization as above is no different than inheriting from a non-template
class. Weirdness only begins to encroach when a class template inherits
from another class template that isn't fully specialized, because a number
of odd rules come into play that all have to do with what the full
specialization might look like at the point of instantiation.
The absence of virtual functions in a class of some substance is a giveaway
that the class wasn't intended to be inherited from, at least not publicly
inherited. The classic example problem consists of deleting an object
through a pointer to its base class subobject, which is undefined when the
base class doesn't have a virtual destructor. This is indeed the case for
CString and std::vector. Many people aren't too convinced by that argument,
but I hope they at least don't hide base class member functions in the
derived class, thinking they are "overriding" them, because they are not.
For example, it would be a bad mistake to implement a function called
"push_back" in your MyElementArray class, because it's just too easy to
call push_back through a base class pointer or reference and think you're
getting the behavior of the derived class version. In addition, any use of
push_back by base class member functions would not resolve to the derived
class version at run-time. For these reasons, I would not publicly inherit
from std::vector, because this form of inheritance is really composition,
and composition is better expressed through private inheritance, or better
still, containment as a member variable.
Visual C++ MVP