Re: [boost] stack-allocated STL-containers

Subject: Re: [boost] stack-allocated STL-containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-08-13 19:54:37

On Fri, Aug 14, 2009 at 12:46 PM, Stefan Strasser <strasser_at_[hidden]>wrote:

> Am Friday 14 August 2009 00:24:54 schrieb Mathias Gaunard:
> > > the vector operates on the stack as long as there is enough space, and
> > > moves to the heap afterwards.
> > > in most cases there is no dynamic allocation.
> >
> > An implementation is free to consider any instance of an allocator with
> > the same arguments passed to the constructor as equal, IIRC.
> >
> > Does your allocator suffer from this issue?
>
> I don't think so. the allocator doesn't have any state except a constant
> pointer to "buffer"(see exmaple above),

The pointer constitutes state.

> so multiple copies of the same
> allocator can be used simultaniously.

Yes, but a default-constructed stack_allocator<> doesn't have storage so it
cannot allocate.

>
> the only c++ standard requirement it can't fulfil is a default constructor.
> I'm not sure why that is needed though. but the standard says that
> Allocator() must be a valid expression.
>
> > Also, is the container still copyable properly?
>
> yes. the only issue that might arise is that the buffer on the stack could
> go
> out of scope before the vector has, as a result of swap()ing the contents
> of
> the vector into another vector with a longer lifetime.
> but I don't think that's a violation of the standard because that is also
> true
> for other allocators, e.g. pool allocators.
>
> Am Friday 14 August 2009 00:00:37 schrieb Christian Schladetsch:
> > Two immediate issues are alignment and the fact that you are using a
> > stateful allocator.
>
> do you consider a constant pointer "stateful", and why is that a problem?

Yes, a pointer is state, and yes it is a problem. STL compliant allocators
cannot have meaningful state. You may wish to search the boost list for the
thread on 'Monotonic Allocator' to witness this being beaten into me over a
period of days.

The only way to do this is to use containers that respect stateful
allocators. It's something I've been arguing for for a while, and these have
now come via Boost.Interprocess.Container, to the proposed Boost.Container
library from Ion. So your proposed stack_allocator<> could possibly work, if
you used Ion's containers. But it is still not general.

What you propose is a subset of a more general allocation model described
here http://tinyurl.com/kkr7af. But you are right about performance
http://tinyurl.com/l7k2op.

Regards,
Christian