Re: [boost] Re: Re: string_algo Formal Review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-22 11:53:12

On Thu, Oct 23, 2003 at 01:36:25AM +1000, Thorsten Ottosen wrote:
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20031022145312.GJ946_at_lenin.felcer.sk...
> [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. If somebody with an
> > experience with
> > this can give me a hand, I'll be very glad.
> >
> > 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. I don't no if your
> implementation can somehow do the
> job faster otherwise.
>

As I said, it is hard to achive the strong guarantie for mutable operations.
For _copy variants, it is guarantied by design, because all input parameters
are const and algorithms have no internal state. So except for the result,
nothing gets changed so in case of exception there is no need for the rollback.

There might be a problem for _copy variants that copy the output
to an output iterator (that obvoiusly get changed), but I don't know what is an expected behaviour
in this case.
 
> > Such a guarantie could bring a heavy degradation of performance.
> 
> 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).
> 

If the container has nothrow erase than trim() can have nothrow guarantie.
But such a specification has to be considered from case to case.

Regards,

Pavol