Re: Shallow\Deep copy
On 7 Oct, 05:14, ManicQin <manic...@gmail.com> wrote:
Hi, I'll do my best to explain my problem...
I have an data type that is wrapping a vector of pointers, currently I
have no control of the type that the vector holds and I need to be as
generic as I can (it's a part of a frame work).
naturally my vector is templated by the client.
I tried to think of a way to deep copy the vector into another ->without<-
adding Clone function and such to the objects and I couldnt
think of one, I would be happy if anyone knows of a way...
Because I couldnt find a way to work without the Clone() AND I cant
force my clients to implement IClonable interface than I decided to
check If the object is descendant of IClonable and if it is than I
deep copy the object if not than I shallow copy the object, it seems
something like this:
void CompositorBase<Interface>::CopyItems(CompositorBase<Interface>
const& compositor)
{
for(CIterator iter = compositor.m_cData.begin();
iter != compositor.m_cData.end();
iter++)
{
Interface* newItem = (*iter);
IClonable* testForClonable =
dynamic_cast<IClonable*>(newItem);
if (testForClonable)
{
IClonable* tmpClone =
testForClonable->Clone();
if (tmpClone)
{
newItem =
dynamic_cast<Interface*>(tmpClone);
}
}
this->AddItem(newItem);
}
}
Now... I dont like this chunk of code, Can any one think of better way
under this restrictions?
thank you!
I think that it is fundamentally wrong to have the behaviour of a
method depend on runtime typing in this way.
It is impossible to document well - "This method does a deep copy
except when it doesn't - and it may be deep in some places and not
others".
Finding bugs will be extremely difficult and you will be the one who
is blamed.
You should either abandon the method entirely since it cannot have a
reasonable function in general or, if you insist, have a partial
specialisation for ICloneable (This probably wont fit in with your
current framework but that would indicate to me that your framework is
flawed).
In my experience developing a framework that isn't strongly grounded
in real application requirements often leads to this sort of mess
where the developer struggles to create something that could do
everything but actually just constrains the users (I'm trying not to
sound too judgemental - I've been guilty myself). From my user point
of view you are making me derive all my classes from your interfaces
just to get some functionality that is harder to maintain than just
using an STL or boost container (and the fact that there is no copy in
the boost pointer containers should tell you something).
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]