«

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

On Tue, 31 Aug 2004 15:46:38 GMT, "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
>

(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

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

"Matthew Hall" <> wrote in message
news:ch2c2h$lr$...
> 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

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?

"spoc" <> schrieb im Newsbeitrag news:y31Zc.17$...
> 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

"spoc" <> skrev i en meddelelse
news:zg4Zc.213$...
>
> "Matthew Hall" <> wrote in message
> news:ch2c2h$lr$...
> > 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

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.

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.

Heinz Ozwirk wrote:

> "spoc" <> 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