On 23 January 2011 19:36, Howard Hinnant <howard.hinnant@gmail.com> wrote:
But if there are correctness issues, I think they trump speed issues.
+1. 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.
I would like to see them copyable (and probably moveable, but I haven't thought that through yet). While the need to copy these things is rare, it still comes up. Calling this StackVector is somewhat of a misnomer, as I'd like to be able to use an object of that type as a member variable, and that aggregate may or may not be on the stack. This is one (but not the only) reason I want it copyable, as types that aren't copyable are a pain to use as member variables.
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.
1. There are times I know the likely largest size of a container, above which I am willing to pay an allocation cost. 2. There are times I want to limit the maximum size of a container. Note: StackVector does not solve all combinations of (1) and (2), but its a good start. :-) -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404