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
>>>> 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)
> 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk