custom allocator using templates

[Robert Frunzke]

Hello,

I need to implement a custom allocator to speed up the allocation of a
specific class in my project and instead of hardwiring it, I would
"templatize"(?) it. The allocator should have minimal overhead and be
used for allocation of a large number of "Node" classes which represent
a hierarchical structure.

The custom allocator has to be at least intrusive as possible for the
user. The allocator has to be somehow bound to the class that uses it.
And the user should not take any note of it. Additionally the work to
bind the allocator to the class should be minimal.

My first approach was to use macros.. but templates should do better.
The result:

template < typename T, size_t pool_size, size_t pool_incr >
class PoolAllocator {
/* .. implementation details omitted .. */
public:
void *operator new( size_t );
void operator delete( void *, size_t );
void *operator new[]( size_t );
void operator delete [] ( void *, size_t );
};

example usage:
class Node; // forward decl.
class Node : public PoolAllocator< Node, 4096, 512 > {
/* .. */
};


Advantages:

1. User can write "Node *n = new Node()" as usual
2. Easy to dock with any class
3. Configurable


Drawbacks:

1. user has to call some kind of static "Node::InitAllocator()" method
to create the pool, or alternatively live with the overhead of checking
it in every new call
2. does not allow inheritance of Node (pool should only have equally
sized objects)
?. any further drawbacks?


Is there a better solution without those drawbacks?


Regards,
Robert

 

[Pete Becker]

Hello,

I need to implement a custom allocator to speed up the allocation of a
specific class in my project and instead of hardwiring it, I would
"templatize"(?) it.

Why a template? One class doesn't require a template. Just provide
class-specific operator new and operator delete.

 

[Robert Frunzke]

Yes, but there may be another class in the project which could be
optimized with the same allocator, or one would like to reuse the
allocator in another project. Then a template would be nice Not a
must-have, yes.

Robert

 

[Pete Becker]

Yes, but there may be another class in the project which could be
optimized with the same allocator, or one would like to reuse the
allocator in another project. Then a template would be nice Not a
must-have, yes.

If you don't know where it's going to be used you can't design it. If
there's "a specific class" that needs special memory management, write
the memory manager for it. Don't do the extra work of generalizing the
memory manager until you understand it and know what extras you need.
Don't make your work harder than it has to be.

 

[Robert Frunzke]

Ok, you may be right. I'll try it this way.

Thank you,
Robert