|
Boost : |
From: scleary_at_[hidden]
Date: 2000-12-04 10:24:18
> [Jeff Garland]
> 2) The pool interface. I'm not fond of the pool interface. The idea of
> pool.construct(...some_parms...)
> just isn't very clean. One common way to do this is to a class specific
> storage pool overriding new/delete for the class. This keeps client code
> closed to the details of how things are allocated. I have uploaded a
> modified version of the pool template called type_specific_pool which
> implements the helper routines (based on pool) which enable a class to
> provide class specific storage using. A class wishing to use this
mechanism
> must create a singleton instance of the type_specific_pool template and
> implement new and delete using the helper functions.
There are several different pool interfaces. A new pool interface is on the
TODO list, which is basically just a B&N base class to provide pool
allocation for its derived class. Then, a user class wanting automatic pool
allocation can just derive from that base class.
It is under development, and is on a "future feature" list. Since I don't
know much about overloading new and delete, I'll be looking at your code
when I get a chance.
-Steve
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk