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:59:01

Felipe Magno de Almeida skrev:
> On Mon, Mar 2, 2009 at 3:38 PM, Thorsten Ottosen
> <thorsten.ottosen_at_[hidden]> wrote:
>> Felipe Magno de Almeida skrev:
> 
> [snip]
> 
>>> 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.
> 
> Can't push_back call reserve if it doesn't fit? That way push_back could
> still be inlineable. Or am I missing something?

Last I checked, vector<T>::push_back() was not inlined, no matter the 
optimization level. The whole involvement of the allocator, and copying
of elements on expansion seems to tell the compile it is inadvisable.
And even if it was inlinable on compiler X, then what about compile Y?

And then there is the additional check for buffer expansion.

>>>> 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?
> 
> I don't think so. But it is quite common it seems.

But nevermind, Peter constructed a (perhaps rare) use-case in another 
branch of this discussion.

-Thorsten