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

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-03-02 12:32:36

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.

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.