Re: virtual operator =
{ Edits: quoted clc++m banner removed. Tip: most newsreader programs
remove the banner automatically. -mod }
On May 9, 9:12 pm, Thiago Adams <thiago.ad...@gmail.com> wrote:
Thanks everyone for the links and answers.
I asked because I want to write the advice: "Don't create the virtual
operator =" and I was trying to find out if it could be useful in some
cases.
I believe that for polymorphic objects the best way is to provide the
function Clone() and always to use pointers or references. In this
scenario the "copy" means: destroy and create a new one.
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.
class base
{
virtual base * Clone() = 0;
virtual void ImplaceClone(base *) = 0;
public:
virtual ~base() {};
void CopyTo(base *& p)
{
// is the same type?
if (p && typeid(*this) == typeid(*p))
{
(*p).~base(); // destroy
ImplaceClone(p); // utilize the same memory
}
else //different
{
delete p; //delete
p = Clone(); // create a new one
}
}
};
#define POLYMORPHIC_COPY_IMP(Class)\
Class * Clone() { return new Class(*this); } \
void ImplaceClone(base * p) { new (p) Class(*this); }
class derived : public base
{
POLYMORPHIC_COPY_IMP(derived);
};
class derived2 : public base
{
POLYMORPHIC_COPY_IMP(derived2);
};
int main()
{
derived d;
base *p = 0;
d.CopyTo(p); // create a copy
derived d1;
d1.CopyTo(p); // create a copy using the same memory
derived2 d2;
d2.CopyTo(p); // delete and create a copy
}
Advices:
- Don't create the "operator =" for polymorphic types. Provide it for
concrete types.
- For polymorphic types use the Clone function.
- Don't make your code more complicated :)
Everyone agrees with these advices?
I don't.
I'm using code where objects are created by an object factory.
Specifically, the code is in a library which doesn't know the exact
type of the objects it will be handling, only certain properties.
Typically, the class definition wasn't even thought of when the
library
was compiled.
The library must be able to create these objects, which it does by
cloning a prototype object, but it sometimes has to assign to an
object.
I don't know how else to handle it without a virtual assignment
operator
(or the equivalent.)
And, yes, it does place the burden on the person who writes the class
of making sure that the assignment makes sense. In our case, it's
not very complicated, since all of the "cloned" objects are (or should
be)
of the same type.
I'm pretty skeptical of "advices", anyway. They turn into dogma (and
serve as the basis for new Holy Wars) much too quickly.
Better to point out the pitfalls (which Scott Meyers does pretty well,
I think), and
let the programmer make the trade-off.
-- Alan McKenney
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]