Re: [boost] Re: basic_format operator= exception safety

From: Samuel Krempp (krempp_at_[hidden])
Date: 2004-01-21 08:06:24

On Sat, 2004-01-03 at 02:49, David Abrahams wrote:
> >>> I can't really understand the invariants of the basic_format class
> >>> but I suspect that its copy assignment operator has exceptions
> >>> safety issue. In case that the operator= is exception safe then it
> >>> only provides the basic guarantee and I wondered if it's was
> >>> intentional?
> >>> Anyway, AFAIKT this function can easily provide the strong guarantee
> >>> using the usual swap idiom without any drawback.

that's true, the operator= was the function most vulnerable to exception
issues (though not as bad as causing leaks or crash), it could leave the
object in an incoherent state (but without consequences).
It's now using the swap idiom.
I think at this point the format class provides the basic guarantee
(thanks to the member objects, since the format class is not handling
memory directly), an exception leaves the format object in a stable
state, but not unchanged. I'll verify this in detail, but I expect that
exceptions can at most lead to partial erasements of the produced string
(or keeping pieces of the previous string and the like).
I'll try to make sure that in any case, calling clear() brings it back
to normal working state (it probably is already true).
And I'll try to have calling clear_notbound() be enough to be back to
normal state. Also the functions that makes the final string from a
format object should either succeed or leave it unchanged (it should be
really easy, if it isnt the case already).

Other than that, I don't see a lot of reason to provide stronger
guarantees, as the user usually cares about the state of the object when
formatting the first item of a pack, and at the end (when all items were
formatted and the format object can produce the result string), but not
the intermediate steps of formatting each item.

Anyhow, thanks for raising the issue, I'll work on that and see what's
reasonable to do.

-- 
Samuel