[janus]

[RuneLancer]

[biggerUniverse]

[tcaudilllg]

Question: it seems to me that the easiest way to copy structured data is to read the data that starts at the address of the structure through the length of the structure, and store the read data into a variable length array. Does this work?

[RuneLancer]

You can do that, yes. Using memcpy, it'd go a little like...

memcpy(StructureA, &StructureB, sizeof(STRUCTURE));

Only this is very dangerous. Assuming you do know that both structures are of the right type and that the one you're copying to has the right amount of data reserved for copying, a straight copy may not always be desirable in OOP. It depends on the situation. For instance, invalidated data still gets copied, whereas a cloneObject method could verify that what's being cloned is valid data. The best example I can think of are pointers being destroyed by another "parent" object and not being set to null (a bad practice to begin with, though.)

There's no "best" way to do anything when programming. Just a "best" way to do something given a specific case. Applying different algorithms to the right situation beats doing brute-force things such as copying an entire structure. Then again, in some cases that is the best solution. :P
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[DrunkenCoder]

In C++ you should *never* I reapeat *never* use memcpy or other straight to the metal copy methods unless you're darn sure that the object being copied is of POD type. A POD (Plain Old Data) type doesn't really qualify as an object it's only a data holder, like a C-struct. Doing bitwise copying of anything that have object semantics is a sure way to give yourself a true headache.

To sum it up, in C++ if you have (a non trival)
copy ctor
dtor
op=

you should (apart from most likely having all three) never ever use memcpy or similar on it.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[DrunkenCoder]

[RuneLancer]

Unless you plan on modifying that data, why not simply create a pointer to it and be done with the whole mess?

So long as you're careful not to end up in a situation where your pointers are desynchronised and you destroy the object without updating the new ones pointing to the same object (which can be very dangerous!)

To handles resources in my game, instead of stupidly reloading the same texture multiple times in memory, I increment its reference count. Whenever something ditches the texture, I decrement the reference count and ONLY delete it when it hits 0. This means I can "copy" a texture between objects in the game world (game objects, not OOP objects), but not waste space with redundant data.

And it illustrates the joys and the power of OOP. Seeing as deleting the texture is a private method that forces the whole reference count check to be done when called and that nothing can ever simply delete the texture without going through the appropriate code first, I can't end up in a dangerous situation short of doing something dumb to begin with (ie, destroying the object forcibly and trying to access its resources anyways; the deconstructor should delete the textures on its own to avoid a leak anyhow, once it goes out of scope.)
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[LeoDraco]