Re: No polymiorphism for virtual operator= ?
On Jul 24, 11:30 am, sun1991 <sun1...@gmail.com> wrote:
Yeah, I got your point. Thanks. I used different parameter in
operator=, so it becomes two different function. Can I say that don=
't
expect virtual operator= to be polymiorphism, because it is not the
way you want? (Sounds like a C++ philosophy question)
If you keep the signature the same (as in the code shown above) in the
derived class, then you have a polymorphic assignment operator. It's an
assignment operator but it's not the copy assignment operator; you can
have as many assignment operators as you want in addition to the copy
assignment operator. When the copy assignment operator is not declared,
and is needed, the compiler generates a copy assignment operator.
When I say philosophy, I mean people usually don't do that,
because it is often a bad design (try to make operator=
polymiorphism), isn't it?
In general, polymophism and value semantics (copy and
assignment) don't go well together. Consider the following:
Base* p1 = new Derived1 ;
Base* p2 = new Derived2 ;
*p1 = *p2 ;
logically, you would expect *p1 and *p2 to be equal after that
(for some suitable definition of equal). But in fact, they will
still have different types; there's no way to dynamically change
the type of an object once it has been created. For this
reason, *most* polymorphic hierarchies will ban assignment (and
make copy private, so that it can only be used in a clone()
function, which creates a new instance).
If you really need value semantics and polymorphism, look up the
letter-envelop idiom. Most of the time, however, I think you'll
find that just using a pointer and/or references is
adequate---this is one case where boost::shared_ptr is often
appropriate.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34