Re: [boost] Interest in StaticVector - fixed capacity vector

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-10-16 02:46:41

On 15 October 2011 17:58, Dave Abrahams <dave_at_[hidden]> wrote:
>> 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
>> messages.
>
> So... had you received a message > 32K, what would have been the
> response of your program?

Deserialization would have failed due to lack of data, thrown an
exception (for stack unwinding) which the higher level interface would
have caught and turned into an error code returned (getting developers
to look at the error code was another story, as the original product
wasn't networked and had 100% reliable message delivery of hard to use
POD messages).
>> 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
> new class.

It's still silent, as it isn't the same interface even though the
actual call looks the same.

When looking for causes of buffer overrun bugs, I can ignore calls to
push_back, insert, resize, etc., because they cannot be the direct
cause since they have no preconditions.  I don't have to go trouncing
back to see what the actual container type is to see if the caller had
to "be careful" (a euphemism for "be perfect") or not.

> I'm not convinced we can maintain that kind of consistency everywhere.

Where are we currently breaking it?  I still think it is a goal we
should strive for.

> These containers may not be able to supply a nonthrowing or
> O(1) swap, either.

In some sense it is O(1), since N is bounded, but I know what you
mean. :-)  swap is one of the places (the only one?) where we cannot
meet the guarantees that std:vector makes.  That just isn't true about
push_back, etc.

My turn to ask a question: why are you so adamant that the unsafe
versions be spelled push_back, etc.?
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]