--- Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote: > E. Gladyshev wrote: > > > * 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. > > An allocator parameter is not the only way to parameterize, here, nor it is > necessarily the most appropriate one. If I wanted to manage how > function/signals allocate their memory, I wouldn't want to do it on a > per-object basis - which, without the typedef templates, is pretty much the > only level the allocator template parameter would allow me to manage it on. > At least for these two libraries, a per-project parameterization seems more > appropriate to the real needs, and something as simple as a trait class > could provide the means.
Right. When we say "consider parametrization", it doesn't necessarily mean a template parameter. Perhaps we should be more specific about it. I agree about trait/policy classes. Just for a note different trait classes could be used in one project I think that it is not really a per-project parameterization (if you need a per-project parameterization, you could as well overload global new/delete). In many cases, you do want to have different memory management strategies in one project depending on the execution context and/or data type. Trait classes don't always prevent it. 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
