[external_allocators] any interest?
Dear all, I have sometimes spoken with people here that had an interest in allocators that could be reset within containers. For example, some have wanted a allocator& container::get_allocator(); member function. One way to solve that problem could be a class like this: template< class Allocator > class external_allocator { public: // forward to Allocator* member }; And then it can be used like this typedef external_allocator< std::allocator<T> > ex_allocator; std::allocator<T> alloc; ex_allocator ex_alloc(alloc); std::vector<T,ex_allocator> vec(ex_alloc); and can now control the allocator from the outside. There seems to only be a small overhead with this approach. One usage scenario I can see would be to use a stack-based allocator on performance critical paths. (because we need the copy-semantics of the container's allocator to be shallow) If there is interest, I can also add the specified member function to the smart containers. or an appropriate member to external_allocator<>. Feedback is welcome -Thorsten
"Thorsten Ottosen" wrote:
I have sometimes spoken with people here that had an interest in allocators that could be reset within containers. For example, some have wanted a
allocator& container::get_allocator(); member function.
The point may be that only container itself is enough to change allocator state, no pointers or external variables that need to be passed down into functions or made global.
One way to solve that problem could be a class like this:
template< class Allocator > class external_allocator { public: // forward to Allocator* member };
With a special allocator, how can one access its specific interface via 'external_allocator'? /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:cp5mrk$h0p$1@sea.gmane.org... | | "Thorsten Ottosen" wrote: | | > I have sometimes spoken with people here | > that had an interest in allocators that could | > be reset within containers. For example, some | > have wanted a | > | > allocator& container::get_allocator(); | > member function. | > | The point may be that only container itself | is enough to change allocator state, no | pointers or external variables that need to | be passed down into functions or made global. yes, that can't be made to work for existing containers in the standard, right? | | > One way to solve that problem could be a class like this: | > | > template< class Allocator > | > class external_allocator | > { | > public: | > // forward to Allocator* member | > }; | > | With a special allocator, how can one access | its specific interface via 'external_allocator'? either a get_internal() member function, like get_allocator().get_internal() or by direct forwarding to the "internal" one in the case of the smart containers. -Thorsten
participants (2)
-
Pavel Vozenilek -
Thorsten Ottosen