Boost logo

Boost :

Subject: Re: [boost] Stack-based vector container
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-01-24 01:22:35

On 24/01/11 02:36, Howard Hinnant wrote:
> I can think of several reasonable answers:
> 1. Does not compile. StackVector can't be copied or moved.
> 2. Compiles and does an element-by-element move on both move construction and move assignment.
> 3. Compiles and does copies based on C++03 rules; no C++0x move semantics.
> > From reading this thread I get that people want StackVector to avoid heap allocations. But I really have no idea how people want StackVector to behave in situations such as the above. And without a clear understanding of such desired behavior, it seems difficult to design.

Throwing my 2cts in here as I went this slippery road already: if we
throw the static/dynamically sized problem out of scope, one must
separate the need of stack allocated container (aka some vector using a
T[N] inside to holds data) which will be copiable/movable on a per
element basis and some platform-specific "stack living" container which
use w/e specific system call to allocate new space in a function stack
(alloca comes ot mind) and have a life span that does not go further
than current scope, thus being non copiable but movable on an element
basis. Both have different use case and provides different benefit: the
first allow for compile-time sized array that ave on new/delete but
otherwise have some similar performance than vector ( operator[] and
iterator are just not that penalizing nowadays, i urge you to rerun the
stepanov_penalty tests), the second has some noticable benefit for
small, funtion local buffers that should not outlive the fucntion call.

So, what do we want here ?

Boost list run by bdawes at, gregod at, cpdaniel at, john at