Re: virtual operator =
On Wed, 9 May 2007 19:12:49 CST, Thiago Adams wrote:
If the objects are the same type verified by typeid we could use the
same memory and the inplace new as an optimization.
I think that is not useful because is too much code and probably one
smart allocator can resolve the optimization problem.
Well I did one experiment for fun.
Comparing typeids on a polymorphic object may well make up for the
time you gain from using explicit destroy and placement new.
Additionally, it's a loss in the case of using Clone(). But
experiments are still fun.
...
#define POLYMORPHIC_COPY_IMP(Class)\
Class * Clone() { return new Class(*this); } \
void ImplaceClone(base * p) { new (p) Class(*this); }
Your code gives me the willies. It also results in undefined behavior
if you try to use CopyTo on a pointer to a local or static object and
the copy constructor throws (3.8/8):
"If a program ends the lifetime of an object of type T with static
(3.7.1) or automatic (3.7.2) storage duration and if T has a
non-trivial destructor, the program must ensure that an object of the
original type occupies that same storage location when the implicit
destructor call takes place; otherwise the behavior of the program is
undefined. This is true even if the block is exited with an
exception."
...
Advices:
- Don't create the "operator =" for polymorphic types. Provide it for
concrete types.
At least don't make it virtual. The abstract base technique from
Meyers' book could still be used.
- For polymorphic types use the Clone function.
This seems to be the common wisdom. In fact, Java provides clone() as
part of the "Object" interface because every object in the language is
polymorphic (and inherits directly or indirectly from Object).
- Don't make your code more complicated :)
At least not with crazy placement-new gymnastics. :)
John Moeller
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]