Subject: Re: [boost] Stack-based vector container
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-01-24 11:53:40
On 23 January 2011 19:36, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> But if there are correctness issues, I think they trump speed issues.
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
> >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_at_[hidden]> (847) 691-1404
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk