@sylvan said:
@Xarium said:
<font>This class alocates memory more efficiently than the standard 'new' and 'delete'.</font>
How do you know this?
Well the usage case I had in mind is allocating tons of small objects...
Oops, sorry, my question was ambiguous, I meant; have you explicitly tested that your system is actually more efficient in a real-world setting?
The standard memory routines might surprise you.
@sylvan said:
Having a template for the type, or just using "sizeof(this)" everywhere I need to know the size?
sizeof(this) will return the size of the system word (say 4 or 8 bytes) because "this" is a pointer.
sizeof(*this) is legal but is unreliable because it is resolved by the compiler at the point it is seen and will return the size of the local (aka definition scope) class rather than the super-class that you actually want.
The prototype of the "new" operator is specifically given a size parameter for these reasons. The value is consistent for the caller not the sub-class, thus you can store this value in the sub-class and always know the size of the super-class that it represents (if you need the size outside the new operator).
A template does much the same thing, but I don't think it is necessary since the underlying code for your class need not change no matter what derives from it.
@sylvan said:
On the other hand I think that basically every single use case for this class would need custom behaviour in the new/delete operators anyway...
Why custom behaviour? A new/delete operator should not get involved in how an object is constructed - the constructor has not been called inside "new" (the object does not exist yet) and the destructor has already been called when inside "delete" (the object is now just a lump of unpredictable memory). Custom behaviour of new/delete should be limited solely to where and how it manipulates memory - it should not use any class level property (other than intrinsics).
@sylvan said:
It's faster when you know you're going to need a large amount of objects of the same size be allocated and deallocated often. So you could use it for your "bullet" class in an action game, say.
Have you considered a simple pool of "free objects" allocated the normal way? ie. freed objects are recycled into the pool - new objects are taken from the pool (unless the pool is empty in which case they are allocated the normal way).
Such a system would have all the same virtues as yours and be much simpler to implement and also be much faster at runtime. The one thing yours might be better at is memory proximity at the start - all objects would be naturally close in proximity getting a small boost through reduction of CPU cache misses (don't read much into this - the difference is likely to be academic).
Bascially, I guess I'm saying that you have used a generic kind of approach (the new/delete approach) to a problem you were seeking a specialised solution for (to avoid the overheads of a general new/delete).
It's a good attempt but I think you either need to generalise your problem domain (allow a true random access memory model) or specialise the implementation more (don't re-implement functionality, like paging, that new/delete already has and is probably better at).