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 12:46:59

Peter Dimov skrev:
> Thorsten Ottosen:
>> John Maddock skrev:
>>>> - From glancing at the implementation posted to the list, it does 
>>>> not appear to
>>>> fall back to heap allocation once the maximum stack capacity is 
>>>> reached.
>>>> push_back() simply asserts that the stack capacity hasn't been used 
>>>> up yet.
>>
>> Yes, that is necessary to make push_back() inlinable.
> 
> It's also necessary if you want to introduce stack buffer overflow 
> attacks. Now, I don't question the right of every C++ programmer to be 
> able to overflow the stack, but I don't like this ability being 
> presented under the name "push_back".
> 
>> I also think this fits most usage scenarios.
> 
> I'm not sure. A typical use case for push_back is when the programmer 
> doesn't know the number of elements in advance.
> 
> for x in w
>    if pred(x)
>        v.push_back(x)
> 
> The typical number of elements satisfying pred may be ~7.1, so making v 
> have a stack capacity of 8 will eliminate a heap allocation and will be 
> a big win. But you can't determine the maximum capacity in advance.

Is it not |w|?

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

And we can add
unchecked_push_back() then.

-Thorsten