On 15 October 2011 17:58, Dave Abrahams <dave@boostpro.com> 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@eviloverlord.com> (847) 691-1404