--- Gregory Colvin <[EMAIL PROTECTED]> wrote: > On Friday, Aug 29, 2003, at 18:16 America/Denver, E. Gladyshev wrote:
> There is a tradeoff between possibly better performance and possibly > unwanted dependancies. This is why we call them guidelines for now. It is up to the developer to consider tradeoffs and make decisions. > > > ... > >> * parameterize only when there is a clear advantage to doing so > > > > I'd modify it to > > > > * Consider parametrization if your library is to be available > > for embedded or non-traditional platfroms. > > Even on "traditional" platforms there may reason to parameterize, and > there may be alternatives to parameterization even on embedded plaforms. OK, * Consider parametrization, especialy if your library is to be available for embedded or non-traditional (like DSP, etc.) platfroms. I think this item will make you think twice before hiding boost::signal's allocator. > > >> * use the standard parameterization mechanisms (Allocator) when > >> choosing to parameterize > > > > I'd add to it > > * Follow boost::allocator specification for allocator parameters > > Which specification is that? There are several here: > http://boost.org/libs/pool/doc/interfaces.html I'd vote for something compatible with STL allocators. So that they can be used with containers directly. Perhaps boost::allocator can extend it a bit wih additional realloc() method. IMO, it is another discussion. 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
