Re: [boost] Stack-based vector container

Subject: Re: [boost] Stack-based vector container
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2011-01-23 20:36:03

On Jan 23, 2011, at 8:13 PM, Emil Dotchevski wrote:

> On Sun, Jan 23, 2011 at 4:46 PM, Howard Hinnant
> <howard.hinnant_at_[hidden]> wrote:
>> On Jan 23, 2011, at 6:59 PM, Emil Dotchevski wrote:
>> 
>>> So the only meaningful way to evaluate the benefits of a std::vector
>>> alternative is to discuss specific use cases, considering other
>>> alternatives as well.
>> 
>> Some use cases:
>> 
>> 1.  swap.
>> 2.  return an auto local from a factory function.
>> 3.  desired behavior when capacity exceeds stack space (go to heap or throw an exception?).
>> 
>> Sometimes std::vector is going to want to transfer memory ownership.  Those are the use cases I would look at first.  What does std::vector<T, stack_alloc<T>> do?  What does stack_vector<T> do?  What do you want to happen?
> 
> Assuming that "we just want it to be faster than std::vector in doing
> X and Y", someone could see the limitations of std::vector as
> nuisance. Yet this is an indication that performance considerations
> will probably trump all other design decisions, since std::vector
> implements a pretty basic concept already. Paraphrasing my earlier
> concerns, the question is are we going to end up with something
> universal enough to be reusable, or will its own limitations become
> nuisance in other (even similar) situations?

I think we are in agreement.

I think there are issues other than speed here, though speed is certainly a big issue.  And I haven't made up my own mind about which direction this project should take.  But if there are correctness issues, I think they trump speed issues.

Let's say we have:

   template <class T> using StackVector = <details we don't know yet>;  // maybe based on std::vector, maybe not

How should this code behave?

bool test0();

template <class T>
StackVector<T>
test1()
{
    StackVector<T> v1;
    StackVector<T> v2;
    // ...
    return test0() ? v1 : v2;
}

int main()
{
    StackVector<std::string> v1 = test1();
    v1 = test1();
}

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.

-Howard