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 ?