[boost] Re: string_algo Formal Review

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-22 11:37:43

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "Pavol Droba" <droba_at_[hidden]> wrote...
> [snip]
>> I haven't done a proper exception safety inspection of the lib. But
>> as far as I understand the concepts in this document, the library
>> satisfies (or it is very close to) the "basic" exception
>> guarantie. 

That's a minimum.  If you haven't got that, you've got a big problem.

>> If somebody with an experience with this can give me a hand, I'll
>> be very glad.

I hope someone else will step in because I am too busy right now.

>> Question is, if there is a requirement, that the "strong" guarantie
>> should be fullfiled.  Obviosly this only applies to mutating
>> algorithms and it is not fulfilled.
>
> For any _copy algorithm I could imagine the strong guarantee by
> making a copy and then running the mutating algorithm on the copy. 

Or simply building the new string with the new data
character-by-character.

> I don't no if your implementation can somehow do the job faster
> otherwise.
>
>> Such a guarantie could bring a heavy degradation of performance.

Find the "natural" level of exception safety for each operation as
described by the link.  It is almost never a good idea to compromise
performance to get exception safety in a library.

> really? I would expect most mutable versions to give the nothrow
> guarantee eg. trim() would never cause a reallocation, but merely
> erase a few elements (using nothrow operations).
>
> I might have overlooked something.

No, you're exactly right.  All the _copy operations should give the
strong guarantee and many others should give the nothrow guarantee,
trivially.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com