Peter Dimov skrev:
Thorsten Ottosen:
John Maddock skrev:
- From glancing at the implementation posted to the list, it does not appear to fall back to heap allocation once the maximum stack capacity is reached. push_back() simply asserts that the stack capacity hasn't been used up yet.
Yes, that is necessary to make push_back() inlinable.
It's also necessary if you want to introduce stack buffer overflow attacks. Now, I don't question the right of every C++ programmer to be able to overflow the stack, but I don't like this ability being presented under the name "push_back".
I also think this fits most usage scenarios.
I'm not sure. A typical use case for push_back is when the programmer doesn't know the number of elements in advance.
for x in w if pred(x) v.push_back(x)
The typical number of elements satisfying pred may be ~7.1, so making v have a stack capacity of 8 will eliminate a heap allocation and will be a big win. But you can't determine the maximum capacity in advance.
Is it not |w|?
The inability to grow also penalizes cases like
for # of rows v.clear() read number of elements into n for each element read it into e, v.push_back(e) process( v.begin(), v.end() )
In this case the programmer wants to reuse v between the rows to minimize the number of heap allocations. But there is no way to know what the maximum n would end up to be.
A good points. FWIW, stlsoft::auto_buffer is resizeable. It's not that hard to add this functionality, though. And we can add unchecked_push_back() then. -Thorsten