By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,650 Members | 1,844 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,650 IT Pros & Developers. It's quick & easy.

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

P: n/a
what is Deep Copy, Shallow copy and Bitwise copy, Memberwise copy?
and what is the difference between them?
pls help
vaibhav

Aug 30 '06 #1
Share this Question
Share on Google+
26 Replies


P: n/a
sa*************@gmail.com wrote:
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/ho...t.html#faq-5.2

Surely google can help you.

Cheers! --M

Aug 30 '06 #2

P: n/a
On 30 Aug 2006 06:06:40 -0700, "mlimber" <ml*****@gmail.comwrote:
>sa*************@gmail.com wrote:
>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:
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
Aug 30 '06 #3

P: n/a
Roland Pibinger wrote:

<snip>
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?
--
Nick Keighley

Aug 30 '06 #4

P: n/a
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
Aug 30 '06 #5

P: n/a
Frederick Gotham posted:

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

That comment should read /* Bitwise Copy */

--

Frederick Gotham
Aug 30 '06 #6

P: n/a
Frederick Gotham schrieb:
(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.
};

int main()
{
MyClass obj1,obj2;

obj2 = obj1; /* Deep Copy */
}
--
Thomas
Aug 30 '06 #7

P: n/a
On Wed, 30 Aug 2006 17:33:50 GMT, Frederick Gotham
<fg*******@SPAM.comwrote:
>what is Deep Copy, Shallow copy and Bitwise copy, Memberwise copy?

(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
Aug 30 '06 #8

P: n/a
On 30 Aug 2006 08:50:43 -0700, "Nick Keighley"
<ni******************@hotmail.comwrote:
>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?
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
Aug 30 '06 #9

P: n/a
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.
Aug 30 '06 #10

P: n/a
On Wed, 30 Aug 2006 22:18:30 +0200, loufoque
<lo******@remove.gmail.comwrote:
>Roland Pibinger wrote :
>OTOH, objects (in the OO-sense) typically are non-copyable

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
Aug 30 '06 #11

P: n/a
Roland Pibinger wrote:
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.

Aug 31 '06 #12

P: n/a
Roland Pibinger wrote:
On Wed, 30 Aug 2006 22:18:30 +0200, loufoque
<lo******@remove.gmail.comwrote:
Roland Pibinger wrote :
OTOH, objects (in the OO-sense) typically are non-copyable
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).
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

Aug 31 '06 #13

P: n/a
On 30 Aug 2006 22:21:51 -0700, "Old Wolf" <ol*****@inspire.net.nz>
wrote:
>Roland Pibinger wrote:
>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.
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
Aug 31 '06 #14

P: n/a
Roland Pibinger wrote:
On 30 Aug 2006 22:21:51 -0700, "Old Wolf" <ol*****@inspire.net.nz>
wrote:
>>Roland Pibinger wrote:
>>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.

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
Aug 31 '06 #15

P: n/a

"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:44*************@news.utanet.at...
On 30 Aug 2006 22:21:51 -0700, "Old Wolf" <ol*****@inspire.net.nz>
wrote:
>>Roland Pibinger wrote:
>>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.

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<CPlayerPlayerList;
CPlayer Player;
Player.LoadData( SomeFile );
PlayerList.push_back( Player ); // Ooops, need copy constuctor for that
Aug 31 '06 #16

P: n/a
On Thu, 31 Aug 2006 04:24:55 -0400, Kai-Uwe Bux <jk********@gmx.net>
wrote:
>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.
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
Aug 31 '06 #17

P: n/a
On Thu, 31 Aug 2006 02:21:59 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>std::vector<CPlayerPlayerList;
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??
Aug 31 '06 #18

P: n/a
Roland Pibinger wrote:
On Thu, 31 Aug 2006 04:24:55 -0400, Kai-Uwe Bux <jk********@gmx.net>
wrote:
>>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.

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

Aug 31 '06 #19

P: n/a

Kai-Uwe Bux wrote:
Roland Pibinger wrote:
On 30 Aug 2006 22:21:51 -0700, "Old Wolf" <ol*****@inspire.net.nz>
wrote:
>Roland Pibinger wrote:
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.
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
I agree. I only disable copy-ctors in singletons and classes wrapping
resource handles.

Diego Martins
HP

Aug 31 '06 #20

P: n/a
"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:44**************@news.utanet.at...
On Thu, 31 Aug 2006 02:21:59 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>>std::vector<CPlayerPlayerList;
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??
I'm actually using very similar code in one of my programs. The reason is,
the Player is logging in with user name and I need to know if the user
exists. In this case I am loading the player with ostream >Player then
checking to see if it's valid (passwords match, user is not banned, etc...).
If, and only if, it is a valid player with correct cridentials do I want to
add this player to my list of players.

The other option is to store a CPlayer* instead of a CPlayer in the vector,
but there is no reason to use pointers just so I won't have to use a copy
constructor.

That's why.
Aug 31 '06 #21

P: n/a
On Thu, 31 Aug 2006 14:38:25 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:44**************@news.utanet.at...
>On Thu, 31 Aug 2006 02:21:59 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>>>std::vector<CPlayerPlayerList;
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??

I'm actually using very similar code in one of my programs. The reason is,
the Player is logging in with user name and I need to know if the user
exists. In this case I am loading the player with ostream >Player then
checking to see if it's valid (passwords match, user is not banned, etc...).
If, and only if, it is a valid player with correct cridentials do I want to
add this player to my list of players.
Ok, let's continue your example above:

std::vector<CPlayerPlayerList;
CPlayer Player;
Player.LoadData( SomeFile );
PlayerList.push_back( Player );

PlayerList[0].run();
Player.stop()

Is your player now running or stopped?

Best wishes,
Roland Pibinger
Sep 1 '06 #22

P: n/a

"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:44*************@news.utanet.at...
On Thu, 31 Aug 2006 14:38:25 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>>"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:44**************@news.utanet.at...
>>On Thu, 31 Aug 2006 02:21:59 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
std::vector<CPlayerPlayerList;
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??

I'm actually using very similar code in one of my programs. The reason
is,
the Player is logging in with user name and I need to know if the user
exists. In this case I am loading the player with ostream >Player then
checking to see if it's valid (passwords match, user is not banned,
etc...).
If, and only if, it is a valid player with correct cridentials do I want
to
add this player to my list of players.

Ok, let's continue your example above:

std::vector<CPlayerPlayerList;
CPlayer Player;
Player.LoadData( SomeFile );
PlayerList.push_back( Player );

PlayerList[0].run();
Player.stop()

Is your player now running or stopped?
After the player is pushed onto the vector I don't use it anymore. And
those are 2 different instances of vectors, not the same one. To answer
your question, one copy of the player is running, one copy of the player is
stopped.

But I'm smart enough not to use the player that was loaded into the vector
from the original isntance.

Your question is similar to saying this:

int X = 10;
int Y = X;

X = 5;
Y = 7;

Is my interger 5 or 7?

Sep 1 '06 #23

P: n/a
On Fri, 1 Sep 2006 01:16:30 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>Your question is similar to saying this:

int X = 10;
int Y = X;

X = 5;
Y = 7;

Is my interger 5 or 7?
5 and 7 are values, your player is an object. That's the difference.
For a short description of the difference between values and objects
(entities) see:
http://www.two-sdg.demon.co.uk/curbr...ctsOfValue.pdf

Best wishes,
Roland Pibinger
Sep 1 '06 #24

P: n/a
Roland Pibinger wrote :
5 and 7 are values, your player is an object.
You seem to confuse objects and entities.

Sep 1 '06 #25

P: n/a
"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:44**************@news.utanet.at...
On Fri, 1 Sep 2006 01:16:30 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>>Your question is similar to saying this:

int X = 10;
int Y = X;

X = 5;
Y = 7;

Is my interger 5 or 7?

5 and 7 are values, your player is an object. That's the difference.
For a short description of the difference between values and objects
(entities) see:
http://www.two-sdg.demon.co.uk/curbr...ctsOfValue.pdf
My player has the value of "Serpardum" also. And, per your example, a value
of Running_ or Stopped_.

And I can come up with many many more reasons to want to copy an object.

Say I'm writing a graphical tool that contains 3 dimentional objects. And
the user wants to copy a 3d object on the screen and make 2 of them. In my
program I may store these in classes, and would simply copy the existing
object to a new one.

Just because *you* can't think of any good reasons to copy objects doesn't
mean they don't exist.
Sep 1 '06 #26

P: n/a
On Fri, 1 Sep 2006 11:56:48 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>Say I'm writing a graphical tool that contains 3 dimentional objects. And
the user wants to copy a 3d object on the screen and make 2 of them. In my
program I may store these in classes, and would simply copy the existing
object to a new one.
The keyword 'class' doesn't indicate whether you have a value type or
an object type. Your 3d object is most probably a value type, e.g.

struct Point {
int x;
int y;
int z;
};
>Just because *you* can't think of any good reasons to copy objects doesn't
mean they don't exist.
<offtopic>
Recently Qt announced a Java library for their framework
(http://doc.trolltech.com/qtjambi-1.0...bi-index.html).
Compare what _they_ consider value types
(http://doc.trolltech.com/qtjambi-1.0...lue-types.html) vs.
what they consider object types
(http://doc.trolltech.com/qtjambi-1.0...ct-types.html).
</offtopic>

Best wishes,
Roland Pibinger
Sep 1 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.