Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-02 13:38:31
Felipe Magno de Almeida skrev:
> On Mon, Mar 2, 2009 at 3:19 PM, Thorsten Ottosen
> <thorsten.ottosen_at_[hidden]> wrote:
>> Thorsten Ottosen skrev:
>> I guess your case above should be implemented as
>> for # of rows
>> v.resize( n );
>> for each element read 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()
> Nor we would for std::vector if we use it the way you suggest.
Right. But vector<T>::unchecked_push_back() does not exists.
>> 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?
It's inlineable. And it doesn't check for a full buffer. The difference
can be anything from not much to really much.
>> 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.
Is that use case different from the above?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk