   Simple problem, copying objects.
  It's been a while since I've coded, and I grew way too rusty.The problem is simple. I need to copy an object.Object being a mesh object, having a bounding volume hierarchy in a binary tree and geometry data, and a lot of other arrays of different sizes, as well as a horde of evil pointers with sharp teeth.I need a copy of this object to place it with the scene for computations of malicious nature.Solution 1:- copy the object with some magical method (memcpy failed me):: Pros -> everything, it's magic:: Cons -> none, it's magicSolution 2: - Create operator= for my class, and then recursively copy stuff (counter productive):: Pros -> Makes code more flexible:: Cons -> hours of coding, debugging, testing and health wasted on reinventing the wheelSolution 3:- Load the object again from file, thus creating a mirror image of the original.:: Pros -> Easy, effortless, precise.:: Cons -> Reading files way too often, rebuilding whole tree with each load, as long as it's low poly, it's neglible, for bigger objects 'tis a pain.I really, really hope that there is a Solution1 available, and I just have no idea where to find it in my dim memory.Here's some obviously not working code :nMesh *test_object = new nMesh();test_object = engine.Objects[0];nVertex xi(100,100,0);memcpy(test_object,engine.Objects[0], sizeof(engine.Objects[0]));test_object->WorldTree->translateBV(xi);Since test_object still points at the object from engine class, the translation operation will be executed on the original. :(Any hints?   
Quote:I really, really hope that there is a Solution1 available, and I just have no idea where to find it in my dim memory.No, there isn't. You cannot automatically copy random memory contents and expect compiler to know what and how to copy.Now, if you were using C++, it would be automatic, since the assignment would be auto-generated.PS: I know your code is written in C++, but since you're using custom pointers and similar horrible practices, you're stuck with recursively copying everything, and hoping you handle everything correctly. With containers and smart pointers, you'd be home free.   ;  Can you elaborate more about the containers and 'smart' pointers?I have 3d data, including mapping, coordinates, normals, and collision detection data in the object, with a binary tree created from spatial partitioning routine. Needless to say, this is a lot of very custom data that needs to be handled.I'd like to learn more about the ways to improve this.   ;  If your object consists entirely of other objects that have copy constructors (including built-in types), then copying Just Works. In your case this probably involves swapping those bare pointers for some sort of smart pointer, and ensuring that the objects pointed to have copy constructors as well. You may have to give some thought to which data actually needs duplicating (ie. that owned by the mesh), and which data just needs a copied reference (ie. that merely referred to by the mesh). Similarly, if you store objects in std::vectors and the like, then it'll handle all the copying for you - providing the stored objects are copyable, that is.Maybe someone else can elaborate on the smart pointers for you, as they're not really my area of expertise (to my shame).   ;  There are plenty of implementations of smart pointers out there [boost has such an implementation that is pretty popular], though they are not hard to create from scratch.  Effectively they are something that overloads all the pointer-relevant operators, and keeps the data with an associated reference counter.  Each constructor/assignment increments the reference counter, each destructor decrements it.  When the references reach zero, the data it is referencing gets deleted.  It's a simple matter of properly overloading things like '*', '->', and being careful with overloading assignment operators.Or you can use one of the hundreds of implementations that are already out there [search for 'smart pointer' or 'shared pointer'].But with regards to assignment, a smart pointer behaves very similarly to a regular pointer [a natural pointer type].  They will not allow you to copy items deep.When you're assigning an object to another object, each member variable has it's respective assignment called [and when you're initializing an object with another object, each member variable's copy constructor is called].  It's a matter of writing proper assignment/copy constructors for the basic building blocks of your objects, then assigning objects is a trivial matter [since the building blocks all have proper assignment operators defined].  Default is member-wise assignment, though when dealing with pointers, you may want a 'deep copy' of an object [which copies the data the pointers reference, as opposed to just the pointer itself], which will require a overloaded assignment operator/copy constructor.Or you can just save the object, and reload it, which is an unfortunately very common means of accomplishing this task [unfortunate because it is wasteful, slow, and often very sloppy].  Make sure you declare the assignment/copy constructors as private though, in this case [since assignment will not be a correct copy], and keep in mind that this makes it impossible to use a huge number of STL containers [since most of them have a requirement of 'assignable' and 'copyable' to organize data internally].   ;Quote:Original post by NestorPLObject being a mesh object, having a bounding volume hierarchy in a binary tree and geometry data, and a lot of other arrays of different sizes, as well as a horde of evil pointers with sharp teeth.Let's see the code: the class body (function implementations shouldn't matter, but the data members certainly are, as well as any 'virtual' specifications, inheritance etc.) and some description of what the pointers are pointing to (i.e. what is their purpose; how are the pointed-at things allocated; who is responsible for cleaning them up?).Quote:Solution 2: - Create operator= for my class, and then recursively copy stuff (counter productive):: Pros -> Makes code more flexible:: Cons -> hours of coding, debugging, testing and health wasted on reinventing the wheelActually, you would be more interested in the copy constructor. (Although when you need either, you generally need both, as well as a destructor.)Actually, for that matter, let's see your destructor too. ;)Quote:nMesh *test_object = new nMesh();test_object = engine.Objects[0];nVertex xi(100,100,0);memcpy(test_object,engine.Objects[0], sizeof(engine.Objects[0]));test_object->WorldTree->translateBV(xi);What on earth do the 'n's stand for?   ;  This is a little bit of a strange idea but might work for ya.Add a pointer to a memory stream.  When you read the file, load the file into the memory stream.  Pass the memory stream to the constructor to create your object.Now when you need more, you can just pass the memory stream again to the constructor as needed.theTroll   