Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at