Re: [boost] Stack-based vector container

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 ?