Thorsten Ottosen skrev:
Peter Dimov skrev:
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.
I guess your case above should be implemented as for # of rows v.clear(); v.resize( n ); for each element read e v.push_back_unchecked(e) process( v.begin(), v.end() ) where v.resize() should never actually shrink the buffer. (Do we need another function that does that?), or should we simply rename v.resize(n) to v.ensure_capacity(n). But as the example above shows, we do not need a growing push_back() here. If the name push_back() is problematic, then I'm all for just calling it something else. But I don't like adding a growing push_back() unless we have a use-case. -Thorsten