   C++ Question (for Game Engine)
  I'm going to start working on a game engine soon mostly for the C++ experience, so I'm ok if it doesn't go anywhere.  I'm in the planning stages, and since this engine may be used by programmers accustomed to Java and unfamiliar with C++, I'm trying to construct the engine so that there is little to no manual memory allocation (all handled behind the scenes through constructors and smart pointers).I am trying to separate the creation of the object and the allocation of the memory for it: I figured this would give more flexibility for my memory management, such as using a memory pool or restricting the amount of memory, as well as make it easy to prevent poorly created objects from creating a memory leak.One difficulty with a game engine is that objects must be created and persist throughout the game loop, which means that using stack variables is not an option.  Say I want to have an abstract class 3DObject, which would be extended by any object that is displayed in a scene.  I was planning using some combination of the Builder and Proxy design patterns so that the client could pass in a sort of blueprint for the object they wanted to create, the engine would allocate memory for it, and then return a proxy to that object in memory.  First of all, is this a good idea?Second, it seems like there are a couple ways of doing this:1.  Make the client design both the class and the class blueprint (seems like unnecessary work, and redundant)2.  Pass in a stack-allocated version of the class derived from 3DObject, and copy the entire object into a heap-allocated version to store in memory.3.  Require objects to have an initialize() function that will be called by the engine, which will allocate the memory required.4.  Overwrite the new operator to call memory allocation functions (or placement new).5.  Pass in an empty templated proxy object, and allocate the memory for the object wherever it should go.Each method has its pros and cons (except the first, that's just all bad it seems):2.  Pretty intuitive for the client, but also could be slow if copying takes awhile.3.  I don't want to assume the user will pay attention and move things that usually go in the constructor to the initialize function.4.  Seems ok, I'm just wary of overwriting new.5.  Seems like the best solution to me, but maybe not intuitive to users that don't use templates often.  Also, this would prevent me from having arguments to the constructor right? (Unless I include a void pointer in the proxy constructor)Let me know if:a) This is a completely stupid idea and I should concern myself with other things.  I don't mind, just thinking about this problem was a good exercise for me.b) It's a legitimate idea but I'm going about it all the wrong ways.or c) One of the above solutions is a good choice.Thanks for the help!Ian   
  Just my $0,02:C++ Programmers will always be required to manage memory manually to some extent, so the users of your engine will have, too. Unless you provide an interface to a managed language like Java or C# which then would impose other restrictions to the design.Assuming that most users will have a Java background I'd say templates and the like should be used carefully.Here are some ideas that might help you:1. Overwrite global new, so that users that allocate their objects on the heap are forced to go through your memory management system. However this might not eliminate memory leaks altogether since they might be introduced by pointers within the client code.2. Don't let client code call constructors for resources like textures etc. Instead provide factories or factory methods that you have control of. Thus your memory management system would always be used in those cases.3. Always return smart pointers to resources that do not allow access to the raw pointer. This would enforce users to use smart pointers only (at the cost of some performance).4. You might also consider using composition over inheritance, i.e. let the user create the base objects via factory methods and allow to add custom behavior objects (strategy pattern and the like).Hope that helps.   ;  I had exactly the same problem for my GUI library. This is what I did (if you want code, just yell!):1. Let every to-be managed object derive from Object, which holds a reference counter (unsigned int) and about 5 member functions to get / set some stuff.2. Create an allocator class, implemented in the library (not templated or _defined_ in header file!) which makes sure its allocated on the library side (ie. if we have a DLL, we don't want to deallocate on exec if its allocated on lib). Library users can derive from this class (and thus make it allocate on the exec side!), using a global variable I set a pointer to an allocator object (so, users can implement memory checking, or memory pools).3. Build a Pointer class, which is a smart pointer with reference counting. Every object pointer passed or retrieved from the library is wrapped in this class.4. Make sure the custom allocator class is used, by overloading global new/delete.Typical syntax:DaevsGUI::Textures::CoronaPointer atlas = new (DaevsGUI::heap) DaevsGUI::Textures::Corona("gui.png");// orusing namespace DaevsGUI;Textures::CoronaPointer atlas = new (heap) Textures::Corona("gui.png");At first, I had it so people passed a _stack_ object, which then got copy constructed to the heap, but that involved one redundant copy. This syntax is not too ugly, it would've been nice without the (DaevsGUI::heap) part, or without explicit 'new', but that makes it only more complicated. This way users can also allocate things NOT for the GUI, by leaving away (DaevsGUI::heap), but it shouldn't matter really.Again, if you need to see code, I can give it you all ;-)Good luck!   