--- Gregory Colvin <[EMAIL PROTECTED]> wrote: [...] > > Does it make sense? > > Not to me. Sounds like a very broken allocator design. >
If I assume that I going to have a full control over my allocator instances (not a very unusual assumption), there is nothing broken here. Whether it is broken or not should be discussed in a specific context. Anyway, my point was that the shared_ptr( Data* p, Deleter ) has a *potential* problem that was not obvious even to to some people here. (it may not be obivous to other developers). Like I said, I don't think that it is a big deal as soon as we state a set of requirements for boost "deleters"/allocators. (STL standard has). The "Common Requirements" section in the shared_ptr description doesn't seem to have them. Perhaps the established requirements will be used by other libraries as well. BTW. I am also concerned about the boost::signals library. It seems like this library could be very usefull for embedded (real-time?) development but it hides std::allocator. If we cannot come up with memory management policies for boost, perhaps we can define a set of no-so-strict guidlines for boost developers. 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
