Boost logo

Boost :

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, gregod at, cpdaniel at, john at