Re: [boost] [utility] new auto_buffer class --- RFC

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:
> 
> [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.

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?

-Thorsten