i''m gonna use a com like system. objects with ref counting will be created on the dynamic lib side. something like this: class def: class one: public base { }; exported func: base* Create(uint type = 0) { if(type == 0) return(new one); } but since OS memory alloc is slow, there are a few tricks to speed this up, like using a object pool. so, i''m thinking bout a kinda smart version of object pool. basically we have a pool of objects, which are not deleted but only marked as dead. when new is called, we first check if any objects in the pool are dead, reset their state and return their addres, if no dead objects found, we use defulat new. the pool size seems to me as the greatest problem. so too handle this, i thought bout a timer, that would count how many new/delete there were in some given time period (ie: one minute) and resize the pool to fit the needs. for example, there could be a period of time when one type of objects is not needed and therefore is a waste to keep a pool of 1000 objects. the only real trouble i see, would be the formula (threshold calculation) for resizing the pool. the basic algo would look like this: - call create - mark time, if time period has elapsed, reset timer and set flag - parse objects, if found dead, reset it, return its address - if not found, use global new - check flag, if flag set, compare number of new/delete with current object pool size, if threshold achived, resize the pool good or bad?

*cough*overengineering*cough*

I should know, I''ve overengineered many a problem. Just do it as simply as you can. If you need a pool then Boost has one.

Sounds a little pointless aswell, seeing as the idea of a memory pool is to speed up the allocation/deallocation of memory, and if you add the ''intelligence'' to it, which resizes the size of the memory pool (read: slow) it will defy the point of the whole thing.

Anyway, I think the enginuity series covers a memory pool in it somewhere aswell, take a look at that if you want.

If you''re calling into a DLL to create/destroy objects often enough that memory allocation is a performance problem, you have a design problem. Changing memory allocation won''t fix that.

If you don''t create/delete objects many times per game step, then the overhead just won''t be a problem; don''t solve a problem you don''t have.

Remember: profile first, optimize second.