From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-30 01:35:55
--- Aleksey Gurtovoy <agurtovoy_at_[hidden]> 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
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.
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