--- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> The allocator design focused on the benefits one
> could get from specialized
> allocators for containers, e.g., data structures
> that may allocate large
> chunks of memory that are expected to be used
> together. They don't really
> give us much for components like shared_ptr that
> allocate one thing
I agree but there is a problem with classes that use
STL and boost components. Here is an example:
template < typename T, typename A = std::allocator<T>
>
class node
{
public:
shared_ptr< T > m_data;
std::list<T, A> m_children;
};
When the user writes
node< MyType, myallocator<MyType> > node;
she will rightfully expect that all memory allocations
of type MyType will use the supplied allocator but
shared_ptr doesn't support it.
The fundamental problem here is that I don't see a
consistent (from the allocation standpoint) way to use
boost and STL components in one class.
>(and
> note that shared_ptr does not allocate the pointer
> it stores, although it
> does allocate a reference count).
How does the reference count get allocated? Do I have
any control over it except overloading the global
new/delete operators? I am writing a module that
needs to use a custom heap for some of my class
instances. The class has a shared_ptr. I guess that I
cannot use shared_ptr there?
Eugene
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
