By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,136 Members | 1,021 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,136 IT Pros & Developers. It's quick & easy.

Building Allocators

P: n/a
Heya everyone!
A Q for U...
I need to build an allocator for my objects, but! the trick is that:

* Allocator would manage his own MemAlloc And the MemFree (like dhu)
* One class could use a few types of allocators (meaning allocator is
not a static member of the class).
* I want the minimal overhead on a programmer, meaning that once he
attached an allocator to an object he wont need to remember what
allocator he attached (fire and forget)

* I could overload new and delete and use the allocator within them

One solution was makin the allocator a member of an object BUT new and
delete are defined as static functions and could only use a static
members. once i'll attach an allocator to an object all objects of the
type will use the same allocator... BAD (think what will happen if i
allocate an object with one allocator and free it with another)

Another solution was adding the allocator to the new and delete
operators, two major problems
1) i could live with specifing the allocator as an argument in the new
operator but, in the delete? two much overhead
2) the overloaded deltet doesnt work! i call it delete(new Allocator())
Object; and it redirects to the normal delete!

I think u got my drift ... its more of a design problem
I'll be happy to hear your thoughts

Jan 2 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
ManicQin wrote:
Heya everyone!
A Q for U...
I need to build an allocator for my objects, but! the trick is that:

* Allocator would manage his own MemAlloc And the MemFree (like dhu)
* One class could use a few types of allocators (meaning allocator is
not a static member of the class).
* I want the minimal overhead on a programmer, meaning that once he
attached an allocator to an object he wont need to remember what
allocator he attached (fire and forget)

* I could overload new and delete and use the allocator within them

One solution was makin the allocator a member of an object BUT new and
delete are defined as static functions and could only use a static
members. once i'll attach an allocator to an object all objects of the
type will use the same allocator... BAD (think what will happen if i
allocate an object with one allocator and free it with another)

Another solution was adding the allocator to the new and delete
operators, two major problems
1) i could live with specifing the allocator as an argument in the new
operator but, in the delete? two much overhead
2) the overloaded deltet doesnt work! i call it delete(new Allocator())
Object; and it redirects to the normal delete!

I think u got my drift ... its more of a design problem
I'll be happy to hear your thoughts
This FAQ gives a handy way of using custom memory allocation for
objects:

http://www.parashift.com/c++-faq-lit...html#faq-11.14

As for allocators, in the terminology of the STL, that means an object
that a container (e.g. std::vector) uses to allocate memory for its
containees. Since in the STL, the container is responsible for creating
and destroying them and the allocator's type is specified at
compile-time as a template parameter, there is less risk that the
object will be deleted by some other allocator.

As for overloaded delete not working, it should. If you consult the
aforementioned FAQ and still can't get it to work, post a minimal by
complete sample that demonstrates the problem (see
http://www.parashift.com/c++-faq-lit....html#faq-5.8).

Cheers! --M

Jan 2 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.