|
|
Home » Community » Coffee corner » NTL - "deep copy semantics"?
NTL - "deep copy semantics"? [message #4116] |
Fri, 21 July 2006 17:57 |
Werner
Messages: 234 Registered: May 2006 Location: Cologne / Germany
|
Experienced Member |
|
|
When reading about "deep copy" I feel a little bit confused.
You call it "deep copy semantics" to put a value into the target while preserving it in the source. And you set this in contrast to "pick transfer semantics" where a value is put into the target while destroying it in the source.
When I compare this with other C++ reading stuff I understand your "deep copy" as a simple copy process while "pick transfer semantics" means the same as "destructive copy semantics". The latter choice of words reserves the expression "deep copy" (vs "shallow" (or "flat") copy) to tell apart memberwise copy from bitwise copy.
Of course you have every right to define expressions to your liking as long as you make clear what you mean (and you do this!). But what is the reason for this non-customary use of these expressions? Or do I misinterpret something?
Werner
|
|
|
|
Re: NTL - "deep copy semantics"? [message #11146 is a reply to message #4121] |
Thu, 23 August 2007 04:17 |
nixnixnix
Messages: 415 Registered: February 2007 Location: Kelowna, British Columbia
|
Senior Member |
|
|
Hi there,
Please ignore this - I found the DeepCopy thing confusing so I leave this here for those who come after me
I don't see any examples of DeepCopy but if I understand correctly, my class, the declaration for which looks like this
class Mine
{
public:
Mine();
double fMember;
int nMember;
Array <Point> m_pts;
};
can be copied with the source in tact so long as I write it
class Mine
{
public:
Mine();
double fMember;
int nMember;
WithDeepCopy<Array <Point> > m_pts;
};
and this means that I can use the default copy constructors and forget about making my own unless I really want to. When I call
Mine mine;
// some initialisation
..
Mine yours(mine);
yours copies mine and they both have all the same members including in their arrays.
Nick
[Updated on: Thu, 23 August 2007 05:31] Report message to a moderator
|
|
|
|
|
|
Re: NTL - "deep copy semantics"? [message #11337 is a reply to message #11324] |
Thu, 06 September 2007 03:05 |
mr_ped
Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
The memory footprint of class VPoint and House is different, which pretty much breaks any chance of direct "polymorphism" in Array.
Pointers to VPoint can be set to point to House too, and the HouseLayer can typecast the pointers back to House pointers in case it is sure there's House and not VPoint upon that pointer.
(or to do checks of type during pointer casting with RTTI)
If you want to keep the DeepCopy behaviour too (i.e. not just to copy pointer value, but actually to create new instance of VPoint or House, copy the data, and set up the pointer to new instance in the copy of PointLayer), you will need to wrap it up in new class like:
class PointContainer {
VPoint *ptr;
...here comes copy constructor which will create new instance of VPoint or House, copy data from old pointer, and set up the new pointer to new copy of PointContainer object...
}
This is IMHO very cumbersome in C++ and some overall class design should be rather changed, than trying to do it this way.
I think using pointers will be probably the right answer for this, but I think you should avoid copy behavior, and suffice with pointers copying only, which will point to shared instance of data. These things are prone to memory leaks, so be careful with memory releasing or use smart pointers / Garbage collector.
Still the PointLayer will work only with VPoint pointers in functions, whenever you will want to work with House instance, you will need to cast the pointer, and that should be done probably only by HouseLayer function, i.e. you can either write all those functions twice with minor changes, or use templates...
Anyway, your PointLayer vs HouseLayer class suggest your class design is too much data oriented, not enough abstract probably.
If House is on same level of abstraction than VPoint (and your usage in Layers suggests so), it should share the basic functions interface with with it (functions for layers to manipulate with them).
I.e.
class VPoint {
virtual MoveMe(...);
virtual HideMe(...);
};
class House : public VPoint {
aditional data;
..custom version of MoveMe() to handle my additional data;
};
class Tree : public VPoint {
different additional data;
..custom version of MoveMe();
};
class Layer {
array of VPoint pointers;
void MoveAllMembers() {
for each in pointers do
pointers->MoveMe(); //I don't care if you are House or Tree or VPoint, just move.
}
}
Actually here the House and Tree is on same level of abstraction, VPoint is base class and shouldn't be used directly too much probably. (Unless it feels right, like in Layer way)
If you want to do something specific upon House, you should either have different list of House objects only, or to have a way to identify House pointers within Layer, typecast them back on House pointer, and call special House functions...
All this should be outside of Layer class, which is not supposed to make difference between VPoint and House or Tree.
I think I can't give you better advice without having better idea what you are trying to do.. and even then I will probably not help you too much, I never really designed any serious OOP application, so I lack experience, I'm more a theory guy..
[Updated on: Thu, 06 September 2007 03:07] Report message to a moderator
|
|
|
|
Goto Forum:
Current Time: Fri Mar 29 00:41:40 CET 2024
Total time taken to generate the page: 0.01424 seconds
|
|
|