Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-15 18:58:23
on Sat Oct 15 2011, Nevin Liber <nevin-AT-eviloverlord.com> wrote:
> On 14 October 2011 05:32, Dave Abrahams <dave_at_[hidden]> wrote:
>> Use-cases, please!
> I worked on a messaging system that created messages via serialization
> (that took iterators) and delivered them via UDP. Most messages were
> small (<100 bytes) with occasional messages 1K-2K in size. To give
> ourselves breathing room, we allowed messages up to, say, 32K, as it
> would be a non-trivial effort to implement splitting/reassembly of
So... had you received a message > 32K, what would have been the
response of your program?
>> How could it ever be a "drop-in replacement for vector"
> For over a decade, the mental model for calling push_back, insert,
> resize, etc. is that it they have no preconditions to check. This is
> true *for every standard container* (which supports the corresponding
> operation, of course). You want to *silently* break that consistency.
You have a point, but you're exaggerating. It's not *silent* if it's a
> That will lead to buffer overrun bugs, which we know are hard to
> debug and
Yes, that's a good point. But that's why I proposed a secure mode.
> I'm not saying we don't need the unchecked functionality. I'm saying
> it should never be spelled p-u-s-h-_-b-a-c-k, i-n-s-e-r-t,
> r-e-s-i-z-e, etc. (which is one of the reasons I'm arguing against
> making it policy based). I'm strongly opposed to any solution that
> uses the same function signatures as the standard containers that
> isn't as safe and easy to call as the ones in the standard containers.
I'm not convinced we can maintain that kind of consistency everywhere.
You have to pay for the optimization of StaticVector with weaker
guarantees. These containers may not be able to supply a nonthrowing or
O(1) swap, either. But if we're going to check anyhow, let's move the
storage to the heap.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk