Boost logo

Boost :

From: Rani Sharoni (rani_sharoni_at_[hidden])
Date: 2004-01-04 08:41:03


David Abrahams wrote:
> "Rani Sharoni" <rani_sharoni_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Rani Sharoni" <rani_sharoni_at_[hidden]> writes:
>>>
>>>> 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.
>>>
>>> The "usual swap" idiom has "usual" drawbacks. Why are they
>>> inapplicable in this case? Strong assignment can always be built on
>>> basic assignment after-the-fact.
>>
>> I explicitly talked about this case in which the throwing operations
>> are the two std::vector assignments. Do you agree that this specific
>> assignment operator is not exception safe
>
> I don't know enough about the implementation of basic_format to make
> a judgement. You are correct to ask about the invariants, though.

I think that I understand your concern about overhead when operation
provides the strong guarantee.
In this case the problem is with the vector assignment which obviously (i.e.
I didn't found it in the standard) provides the basic guarantee due to
overhead considerations of such general facility.

I wanted to figure out a clear idiomatic guideline about cases like
basic_format in which operation with basic guarantee is needed but
preserving the invariants might be difficult. The first thing that I thought
about is that there must be some implementation penalty for such
optimizations.
The non optimized strong guarantee is easy to accomplish but the overhead,
for extremely rare throwing cases, is in the usual code path. The "overhead"
probably should be in the exceptional code path.

Thanks,
Rani


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk