using memcpy to copy classes

[spoc]

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this bug am getting some odd crashes and
maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here
is an example of what I'm doing, I know in isolation it may seem odd. I am
presuming this will copy all data ok but not really sure of the workings and
implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Cheers, spoc

[Bob Hairgrove]

On Tue, 31 Aug 2004 15:46:38 GMT, "spoc" <sp**@enterprise.com> wrote:

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this bug am getting some odd crashes and
maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here
is an example of what I'm doing, I know in isolation it may seem odd. I am
presuming this will copy all data ok but not really sure of the workings and
implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Cheers, spoc

(Is this a FAQ??)

It is always a BAD IDEA to copy class objects using "dumb copy"
semantics (i.e. bit-for-bit copying) because you might be copying
pointers to allocated memory which is deleted when the first class to
be deleted is destroyed; accessing them through the other class will
lead to undefined behavior. Without knowing the exact layout of your
class, it is hard to know.

A class is usually much more sophisticated than a struct because it
will implement its own semantics for copying. Also, a class can
prohibit copying (i.e. copying the "normal" way) by declaring its copy
constructor and/or assignment operator private. In my first paragaph,
you might copy pointers (shallow copy) but you are sharing the memory
they point to; typically, the class will arrange either to do a deep
copy, by allocating additional storage and copying all the data the
pointers are referencing, or -- much more complicated -- implementing
some kind of reference count.

Even if the class declaration looks relatively harmless, it might have
some members which are themselves classes (e.g. std::string,
std::list, etc.).

IOW, don't do it!

--
Bob Hairgrove
No**********@Home.com

[Matthew Hall]

spoc wrote:

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this bug am getting some odd crashes and
maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here
is an example of what I'm doing, I know in isolation it may seem odd. I am
presuming this will copy all data ok but not really sure of the workings and
implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Cheers, spoc

What is the definition of the class o? And what do you consider
"standard types". If o contains strings, vectors, or any non-primitive
type, you run the risk of undefined behavior, and hence crashes since
strings, vectors, etc allocate memory internally.

If 'o' consists only of floats, chars, ints, and fixed-size arrays of
such, then memcpy should work, I believe. Pointers are OK to copy, just
don't use them to manage memory (as you say you don't)

Does class 'o' have virtual functions or multiple bases?

And, could you fill us in on why you _must_ use memcpy? I can only think
of one reason (speed) though I imagine there are others.

-matt

[spoc]

"Matthew Hall" <ma****@math.uiuc.edu> wrote in message
news:ch*********@news.ks.uiuc.edu...

spoc wrote:

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this bug am getting some odd crashes and maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here is an example of what I'm doing, I know in isolation it may seem odd. I am presuming this will copy all data ok but not really sure of the workings and implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Cheers, spoc

What is the definition of the class o? And what do you consider
"standard types". If o contains strings, vectors, or any non-primitive
type, you run the risk of undefined behavior, and hence crashes since
strings, vectors, etc allocate memory internally.

If 'o' consists only of floats, chars, ints, and fixed-size arrays of
such, then memcpy should work, I believe. Pointers are OK to copy, just
don't use them to manage memory (as you say you don't)

Does class 'o' have virtual functions or multiple bases?

And, could you fill us in on why you _must_ use memcpy? I can only think
of one reason (speed) though I imagine there are others.

-matt

Hi Mat

I'm using chars, ints and fixed arrays only. The class has just one base and
DOES contain a few virtual functions. To be honest I'm using memcpy without
understanding how the class and it's base is organised in memory and the
virtual functions etc. So I guess it's a bad idea.

The reason I'm doing this is because I'm hacking some of my old code and am
in a bit of a rush.

Cheers,

Spoc

[Rolf Magnus]

spoc wrote:

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this
Which would be ...?
bug am getting some odd crashes and maybe I'm doing something dodgy
copying classes like this? The classes contain no dynamicaly allocated
data, just standard types and arrays. Here is an example of what I'm
doing, I know in isolation it may seem odd. I am presuming this will copy
all data ok but not really sure of the workings and implications of doing
it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Should work if your class o is a POD type. But what's wrong with the copy
constructor?

[Heinz Ozwirk]

"spoc" <sp**@enterprise.com> schrieb im Newsbeitrag news:y3************@newsfe1-win.ntli.net...

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this bug am getting some odd crashes and
maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here
is an example of what I'm doing, I know in isolation it may seem odd. I am
presuming this will copy all data ok but not really sure of the workings and
implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...


// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)


Is this ok?

No! There might be some situations, where memcpy might work, but don't worry about them. If your compiler is worth its price, it should be able to find out what is the "best" way to copy an instance of some class type. Leave it to your compiler to decide how to assign values to variables. The compiler will recognize when you make changes to your class that will require more complex assignment, and it can also handle conversions between different types, that memcpy cannot handle. In your case, simply write

*c1 = *c2;

and let the compiler do the dirty part of the work.

Heinz

[Peter Koch Larsen]

"spoc" <sp**@enterprise.com> skrev i en meddelelse
news:zg*************@newsfe5-gui.ntli.net...

"Matthew Hall" <ma****@math.uiuc.edu> wrote in message
news:ch*********@news.ks.uiuc.edu...

spoc wrote:

I have been using memcpy to copy one class to another of the same type. There are reasons why I had to do this bug am getting some odd crashes and maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here is an example of what I'm doing, I know in isolation it may seem odd.

I

am presuming this will copy all data ok but not really sure of the

workings

and implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Cheers, spoc
What is the definition of the class o? And what do you consider
"standard types". If o contains strings, vectors, or any non-primitive
type, you run the risk of undefined behavior, and hence crashes since
strings, vectors, etc allocate memory internally.

If 'o' consists only of floats, chars, ints, and fixed-size arrays of
such, then memcpy should work, I believe. Pointers are OK to copy, just
don't use them to manage memory (as you say you don't)

Does class 'o' have virtual functions or multiple bases?

And, could you fill us in on why you _must_ use memcpy? I can only think
of one reason (speed) though I imagine there are others.

-matt

Hi Mat

I'm using chars, ints and fixed arrays only. The class has just one base

and DOES contain a few virtual functions. To be honest I'm using memcpy without understanding how the class and it's base is organised in memory and the
virtual functions etc. So I guess it's a bad idea.

The reason I'm doing this is because I'm hacking some of my old code and am in a bit of a rush.
Okay.... then just continue your memcpy'ing. That way you'll continue being
in a rush forever ;-)


Cheers,

Spoc

Skål,
Peter

[Rolf Magnus]

spoc wrote:

I'm using chars, ints and fixed arrays only. The class has just one base
and DOES contain a few virtual functions.
Ok, so your class is _not_ POD and memcpy is unlikely to work as you expect.
To be honest I'm using memcpy without understanding how the class and it's
base is organised in memory and the virtual functions etc. So I guess it's
a bad idea.
Yes, it is.
The reason I'm doing this is because I'm hacking some of my old code and
am in a bit of a rush.

Just use the copy constructor instead of memcpy. So replace your:

memcpy(c1, c2, sizeof(*c1));

with:

*c1 = *c2;

and you're done.

[Karthik Kumar]

spoc wrote:

I have been using memcpy to copy one class to another of the same type.
There are reasons why I had to do this bug am getting some odd crashes and
maybe I'm doing something dodgy copying classes like this? The classes
contain no dynamicaly allocated data, just standard types and arrays. Here
is an example of what I'm doing, I know in isolation it may seem odd. I am
presuming this will copy all data ok but not really sure of the workings and
implications of doing it this way:

o* c1 = new o();
o* c2 = new o();

// various inits on both c1 and c2...
// copy c2 over c1 and delete c2
memcpy(c1, c2, sizeof(*c1));

delete c2;

// continue working with c1 (which is a copy of the deleted c2)
Is this ok?

Cheers, spoc

How about having your implementation of the copy constructor and the
assignment operator . That would be a natural solution to the given
problem at hand, in C++.

--
Karthik.

[Rich Grise]

Heinz Ozwirk wrote:

"spoc" <sp**@enterprise.com> schrieb im Newsbeitrag

Is this ok?

No! There might be some situations, where memcpy might work, but don't
worry about them. If your compiler is worth its price, it should be able
to find out what is the "best" way to copy an instance of some class type.
Leave it to your compiler to decide how to assign values to variables. The
compiler will recognize when you make changes to your class that will
require more complex assignment, and it can also handle conversions
between different types, that memcpy cannot handle. In your case, simply
write

*c1 = *c2;

and let the compiler do the dirty part of the work.

Is this what people are talking about when they say "use the copy
constructor"? IOW, is (writing/compiling/executing '*c1 = *c2;')
an instance of (use the copy constructor)?

(sorry, the book I'm on doesn't mention "the copy constructor" (always
with the 'the', like there's only one) until chapter 10, and I'm at
1 1/2. :-)
http://www.mindview.net/Books/TICPP/...ngInCPP2e.html

Thanks,
Rich

[Rich Grise]

Rich Grise wrote:

Heinz Ozwirk wrote:

"spoc" <sp**@enterprise.com> schrieb im Newsbeitrag

Is this ok?

No! There might be some situations, where memcpy might work, but don't
worry about them. If your compiler is worth its price, it should be able
to find out what is the "best" way to copy an instance of some class
type. Leave it to your compiler to decide how to assign values to
variables. The compiler will recognize when you make changes to your
class that will require more complex assignment, and it can also handle
conversions between different types, that memcpy cannot handle. In your
case, simply write

*c1 = *c2;

and let the compiler do the dirty part of the work.

Is this what people are talking about when they say "use the copy
constructor"? IOW, is (writing/compiling/executing '*c1 = *c2;')
an instance of (use the copy constructor)?

(sorry, the book I'm on doesn't mention "the copy constructor" (always
with the 'the', like there's only one) until chapter 10, and I'm at
1 1/2. :-)
http://www.mindview.net/Books/TICPP/...ngInCPP2e.html

Never mind - whoever writes the class writes the copy constructor. Duh.

Cheers!
Rich