--- Peter Dimov <[EMAIL PROTECTED]> 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>
struct X
{
std::list<T> l;
};
OR
template<typename T, typename A=stl::allocator<T> >
struct X
{
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?
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
