Not sure exactly what you mean, but wouldn't a derived GameObject class do that?

First general rule of optimization is neither worry nor act on things that might happen. Life is too short for that.

Instead, only fix the problems you are sure about they will make your life miserable, and happily ignore all other problems.

Second rule of optimization is measure! Yes, dynamic allocation might be slow, but maybe it's not. Or, yes it's slow, but you do it only once, so optimizing it away won't even be noticable. On the other hand, right next to it is a piece of code that eats CPU time like a madman! Let's fix that instead!

It's impossible to predict where performance problems will happen. In all my attempts in finding such sources of trouble I always make a guess where it is, and so far I am 100% consistently wrong. It's always somewhere else, at a spot you never ever suspected.

Third rule of optimization is after fixing measure again that you fixed it.

Note that your current path is already costing you time. Instead of coding a normal solution now, you're thinking about some complicated scheme to shave off some unknown amount of milli-seconds CPU time, assuming you actually need to save those milli-seconds.

So unless you are sure you know stuff will fail if you code it in a simple straightforward manner, I would say don't worry about it. Even if it turns out that the problem is real, changing a working but slow program into something faster is simpler than trying to build a fast and working program from scratch when you don't even know where “slow” is coming from.

EDIT: Fourth rule of optimization is stop optimizing when it's fast enough. Making it even faster is generally possible, but doesn't gain you anything.

Btw. you should somehow manage your overall memory, not just those of objects. This won't help ya just in decreasing fragmentation but also finding leaks in your code.

You can for example allocate a big blog of memory at the beginning and then use that block to allocate your objects in. You can use different memory blocks for different sized objects (small object heap vs. large object heap) or use a garbage collection pattern which moves memory around and you only access those memory with another indirection.

I recommend this from time to time http://bitsquid.blogspot.com/2010/09/custom-memory-allocation-in-c.html​

@DevReign I'm doing something like this for a game where the player kills robots. I have a seperate pool for each type of robot. When the game is started different types of robots can be moved to a vector of type Robot_Base* . In the game loop, I can update each robot by using like this:

for (Robot_Base* &pRobot: vRobots)

pRobot→Update(DeltaTime);

Different behaviors are obtained by overriding a pure virtual Attack() function:

virtual void Robot_Base::Attack() =0; //Abstract Class

void Robot_Melee::Attack(); //This is derived from Robot_Base, the attack function contains code to make the robot punch a target

void Robot_Bomber::Attack(); //This is derived from Robot_Base, the attack function contains code to make the robot launch a bomb

If the robot dies, its status is set to dead, and moved out of the vRobots vector and back into its resource pool. This prevents problems with dead pointers since it's not deleted.

You could make one class of robot and use one resource pool. You would have to encapsulate things that would be different - like how they attack the player, or move around. Maybe give the robot a pointer to Attack_Base, but have derived classes like Attack_Punch and Attack_Bomb.

In my case, The robots have different modes of movement (flying, walking, running, rolling), different meshes, different voices, different weapons, etc. I found it easier to use separate resource pools rather than trying to encapsulate all the differences.