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

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-16 07:50:37

on Sun Oct 16 2011, Nevin Liber <nevin-AT-eviloverlord.com> wrote:

> On 15 October 2011 17:58, Dave Abrahams <dave_at_[hidden]> wrote:
>
>>> 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.

Well, now we could pick nits over the meaning of "same interface."  I
still think it's an exaggeration.  It's got to be legitimate to discover
that the concepts you've been using all along refine some
less-constrained concept, but whatever.  My point is, you have a point.
:-)

> 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.

Having to be careful is evil, agreed.

>> 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.

See below.

>> 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. :-)  

There's also the nonthrowing part.

> 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.?

I'm not.  If you think I am, you've misconstrued me.  I'm just trying to
understand the design space and represent a point-of-view about handling
likely programmer errors that I think is important and overlooked.

I do very much dislike the idea of having multiple interfaces for what
is essentially the same semantics.  There are certainly applications
where it's knowable statically that the limit can never be violated
where one might want to drop in a bounded vector in place of
std::vector, and having to spell push_back some other way, as though it
were essentially different, is ugly.  That's one reason I'm being pushed
toward "policies" (i.e. a CapacityHandler) for this case.  It would
still force the user not to ignore the boundary case without forcing him
to accept an exception when it's not appropriate.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com