On Mon, Mar 2, 2009 at 3:19 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Thorsten Ottosen skrev:
[snip]
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.
Nor we would for std::vector if we use it the way you suggest.
If the name push_back() is problematic, then I'm all for just calling it something else.
How is the usage you shown faster than a growing push_back?
But I don't like adding a growing push_back() unless we have a use-case.
The use-case seems obvious to me. A vector that can use stack-allocation for >90% of the cases for an application. As someone pointed out, signals2 uses one in a detail namespace.
-Thorsten
Regards, -- Felipe Magno de Almeida