Boost logo

Boost :

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

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

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at