From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-23 13:13:14
--- Peter Dimov <pdimov_at_[hidden]> wrote:
> In this context, an allocator parameter is only an excuse for implementors
> to avoid doing the necessary work to make function<> useful out of the box.
> "You can always use a custom allocator", right?
Considering the variety of real life requirements and platforms, it is not practical to make a
library that work out of the box. That is why STL has allocators. In one project, if STL did not
have allocators, I would have to implement my own containers. I was so happy that I didn't have
to do it.
At least a library should be consistent about memory management.
The issue is how consistent boost is about it (STL is very consistent)? It seems that boost
doesn't have any idea about how it manages its memory.
For example if a boost class X uses std::list, does it have to expose the std::list<> allocator or
should it use the standard std::allocator<>.
template<typename T, typename A=stl::allocator<T> >
std::list<T, A> l;
Which definition is more friendly to boost?
Is it allowed for a boost libarary to use global new/delete? If so, should it be documented?
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk