what is Deep Copy, shallow copy and bitwises copy.?

[saxenavaibhav17]

what is Deep Copy, Shallow copy and Bitwise copy, Memberwise copy?
and what is the difference between them?


pls help
vaibhav

 

[mlimber]

what is Deep Copy, Shallow copy and Bitwise copy, Memberwise copy?
and what is the difference between them?

What is a homework question? See this FAQ:

http://parashift.com/c++-faq-lite/how-to-post.html#faq-5.2

Surely google can help you.

Cheers! --M

 

[Roland Pibinger]

What is a homework question? See this FAQ:

It doesn't sound like homework. The question is not covered in the C++
FAQ. I cannot quickly find a link with decent explanations. The
answers are not entirely trivial (e.g.: For which objects is a bitwise
copy appropriate? When is a memberwise copy shallow, when deep? ...).
Nobody should hold back answers.
BTW, copy constructors almost never need to be implemented but should
be made private (without implementation).

Best regards,
Roland Pibinger

 

[Nick Keighley]

Roland Pibinger wrote:

BTW, copy constructors almost never need to be implemented but should
be made private (without implementation).

why? Doesn't copy construction very often make semantic sense?

 

[Frederick Gotham]

what is Deep Copy, Shallow copy and Bitwise copy, Memberwise copy?

(1) Shallow Copy and Memberwise copy (They're equivalent)

struct MyStruct {
int *p1;
double *p2;
};

int main()
{
MyStruct obj1 = {new int,new double};

MyStruct obj2;

obj2 = obj1; /* Shallow or Memberwise */
}

(2) Bitwise Copy

#include <cstdlib>
using std::memcpy;

struct MyStruct {
int *p1;
double *p2;
};

int main()
{
MyStruct obj1 = {new int,new double};

MyStruct obj2;

memcpy(&obj2,&obj1,sizeof obj2); /* Shallow / Memberwise */
}

Note that a Bitwise Copy will also copy any padding between and after
members.

(3) Deep Copy

class MyClass {
int *p;

public:

MyClass() : p(new int) {}

MyClass(MyClass const &) : p(new int) {}
};

int main()
{
MyClass obj1,obj2;

obj2 = obj1; /* Deep Copy */
}

 

[Frederick Gotham]

Frederick Gotham posted:

memcpy(&obj2,&obj1,sizeof obj2); /* Shallow / Memberwise */

That comment should read /* Bitwise Copy */

 

[Thomas J. Gritzan]

(3) Deep Copy

class MyClass {
int *p;

public:

MyClass() : p(new int) {}

MyClass() : p(new int()) {}

MyClass(MyClass const &) : p(new int) {}

MyClass(MyClass const &rhs) : p(new int(*rhs.p)) {}

Should copy something.

 

[Roland Pibinger]

(1) Shallow Copy and Memberwise copy (They're equivalent)

Are they equivalent? Doesn't 'memberwise' just mean 'member by member'
which may result in a deep or a shallow copy depending on the members.

Best wishes,
Roland Pibinger

 

[Roland Pibinger]

why? Doesn't copy construction very often make semantic sense?

For 'value types' the compiler-generated copy constructor is usually
the best. OTOH, objects (in the OO-sense) typically are non-copyable
and therfore need no copy constructor implementation, just a
private(ly) declared copy constructor (to make them non-copyable).

Best wishes,
Roland Pibinger

 

[loufoque]

Roland Pibinger wrote :

OTOH, objects (in the OO-sense) typically are non-copyable

Please don't confuse your personal beliefs with programming theory.
I see no reason why objects would typically be non-copyable. Especially
in C++ which is based on copy semantics.
On the contrary, most objects should be copyable, unless they manage
some kind of unique resource (sockets, files, ...).

Moreover, if you want to make your object non-copyable clearly says so
instead of saying "write a private constructor". Actually, inheriting
from boost::noncopyable is probably clearer.

 

[Roland Pibinger]

Roland Pibinger wrote :


Please don't confuse your personal beliefs with programming theory.

I don't.

I see no reason why objects would typically be non-copyable.

Why should objects be duplicated? What should it mean? Eg.

Person dilbert;
Person wally (dilbert); // ???

Especially in C++ which is based on copy semantics.

and reference/pointer semantics ...

On the contrary, most objects should be copyable, unless they manage
some kind of unique resource (sockets, files, ...).

Objects have identity. The can be referenced by multiple refences but
it hardly makes sense to duplicate them. (Even in OO languages like
Java objects are hardly ever 'cloned' even though a Clonable interface
exists).

Moreover, if you want to make your object non-copyable clearly says so
instead of saying "write a private constructor". Actually, inheriting
from boost::noncopyable is probably clearer.

Making the class dependant on Boost just to make it non-coppyable??

Best wishes,
Roland Pibinger

 

[Old Wolf]

Why should objects be duplicated? What should it mean? Eg.

Person dilbert;
Person wally (dilbert); // ???

Sheep dolly (bill);

Anyway, copy-constructors are also used for moving objects
around in memory. For example, returning an object from a
function, or storing an object in a container than can re-allocate
its memory. The new object is copy-constructed from the
original and the original is then destroyed.

 

[m_schellens]

I don't.


Why should objects be duplicated? What should it mean? Eg.

Person dilbert;
Person wally (dilbert); // ???


and reference/pointer semantics ...


Objects have identity. The can be referenced by multiple refences but
it hardly makes sense to duplicate them. (Even in OO languages like
Java objects are hardly ever 'cloned' even though a Clonable interface
exists).

Sorry, but saying objects should not be copied in such a general way
is just plain BS.

One (out of many) more example is if you compose your object from
others. Then you might need to copy the contained objects form several
others to form a newly composed (individual) object.

Marc

 

[Roland Pibinger]

Sheep dolly (bill);

Anyway, copy-constructors are also used for moving objects
around in memory. For example, returning an object from a
function, or storing an object in a container than can re-allocate
its memory. The new object is copy-constructed from the
original and the original is then destroyed.

What you can do in C++ is different from what is desirable. Having
duplicate objects (objects (in the OO sense), not values) of the same
entity in your program is harldy ever a Good Thing (at least I can
quickly think of no case where it is).

Best regards,
Roland Pibinger

 

[Kai-Uwe Bux]

What you can do in C++ is different from what is desirable. Having
duplicate objects (objects (in the OO sense), not values) of the same
entity in your program is harldy ever a Good Thing (at least I can
quickly think of no case where it is).

Keep in mind, though, that C++ supports various other viable styles of
programming, where your orignial remark

BTW, copy constructors almost never need to be implemented but should
be made private (without implementation).

hardly is applicable. I find that value semantics is the most appropriate
model for most of my programming and copy constructors need to be defined
in most cases. In the vast variety of what can be done well in C++, strict
OO programming is but a small fraction; and advice targeted to OO design
proper is of very limited scope when talking C++.


Best

Kai-Uwe Bux

 

[Jim Langston]

What you can do in C++ is different from what is desirable. Having
duplicate objects (objects (in the OO sense), not values) of the same
entity in your program is harldy ever a Good Thing (at least I can
quickly think of no case where it is).

std::vector<CPlayer> PlayerList;
CPlayer Player;
Player.LoadData( SomeFile );
PlayerList.push_back( Player ); // Ooops, need copy constuctor for that

 

[Roland Pibinger]

Keep in mind, though, that C++ supports various other viable styles of
programming, where your orignial remark


hardly is applicable. I find that value semantics is the most appropriate
model for most of my programming and copy constructors need to be defined
in most cases.

What I mean is that copy constructors are either trivial for values
(and therfore need not be implemented) or should be made private (and
left unimplemented) for objects.

Best wishes,
Roland Pibinger

 

[Roland Pibinger]

std::vector<CPlayer> PlayerList;
CPlayer Player;
Player.LoadData( SomeFile );
PlayerList.push_back( Player ); // Ooops, need copy constuctor for that

PlayerList.push_back( Player ); // Ooops, why would you duplicate
your CPlayers??

 

[Kai-Uwe Bux]

What I mean is that copy constructors are either trivial for values
(and therfore need not be implemented) or should be made private (and
left unimplemented) for objects.

That copy constructors for classes with value semantics are trivial, is not
true in my experience. It does not apply to any container like class, e.g.,
a matrix class. Similarly classes that model graphs or cell complexes are
very much similar to containers -- it would be hard and inefficient to try
implementing them just using standard containers. Also, whenever you choose
a COW implementation for efficiency, you will have to deal with your own
copy constructor.

The validity of your remark depends very much on the problem domain that you
are dealing with. The way you state it, to me, seems to be a vast
over-generalization.


Best

Kai-Uwe Bux

 

[Diego Martins]

Keep in mind, though, that C++ supports various other viable styles of
programming, where your orignial remark


hardly is applicable. I find that value semantics is the most appropriate
model for most of my programming and copy constructors need to be defined
in most cases. In the vast variety of what can be done well in C++, strict
OO programming is but a small fraction; and advice targeted to OO design
proper is of very limited scope when talking C++.


Best

Kai-Uwe Bux

I agree. I only disable copy-ctors in singletons and classes wrapping
resource handles.

Diego Martins
HP