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?
template <class T>
return test0() ? v1 : v2;
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk