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

S

saxenavaibhav17

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


pls help
vaibhav
 
R

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
 
N

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?
 
F

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 */
}
 
T

Thomas J. Gritzan

Frederick said:
(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.
 
R

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
 
R

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
 
L

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.
 
R

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
 
O

Old Wolf

Roland said:
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

m_schellens

Roland said:
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
 
R

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
 
K

Kai-Uwe Bux

Roland said:
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
 
J

Jim Langston

Roland Pibinger said:
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
 
R

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
 
R

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??
 
K

Kai-Uwe Bux

Roland said:
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
 
D

Diego Martins

Kai-Uwe Bux said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top