Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Peter Dimov (pdimov_at_[hidden])
Date: 2009-03-02 12:32:36
> 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
> 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
> 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk