On Jan 23, 2011, at 8:13 PM, Emil Dotchevski wrote:
On Sun, Jan 23, 2011 at 4:46 PM, Howard Hinnant <howard.hinnant@gmail.com> 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