Re: [boost] Boost memory management guidelines

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-08-30 22:15:14

E. Gladyshev wrote:
> --- 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
> global new/delete).

I meant per-project parameterization of 'function'/'signal' allocation
strategy, not of every memory allocation in the system.

> 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.

Sure. My main point was that in the particular case you've cited an
allocator parameter won't even cover what I consider to be the most
realistic use case.

Aleksey