[boost] Re: Re: Basic guarantee and synchronized multiple updates.

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-09-27 11:04:19

"David Abrahams" <dave_at_[hidden]> wrote in message
news:049201c26632$9187a8a0$6501a8c0_at_boostconsulting.com...
>
>
> ----- Original Message -----
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>
> > Right.
> > I forgot to mention that the sort of sequences that I was considering
are
> of
> > objects which themselves provide exception-safe copy construction.
>
> Don't say "exception-safe". It's an imprecise term. Any type which
> documents the exception behavior of its copy constructor and fulfills it
is
> "exception-safe".
>
OK.

> Every type which provides the basic guarantee for its copy constructor
also
> provides the strong guarantee (unless it somehow mutates its argument or
> touches global state), so your statement above has little meaning.
>
> Maybe you just meant "objects which don't throw from their copy
> constructors". Pretty limiting.
>
Yes, that's what I meant. And it seems that it is not as usual as I thought.

> > In
> > practice, this means that the sequence is of managed pointers (i.e.
> > shared_ptr<>) which don't throw during copy construction.
>
> > > > w.r.t to the containers (assuming that the transfers are "basically
> > > > exception safe"),
> > >
> > > ??? What does this mean?
> > >
> > I meant: assume that the element's copy-ctor don't throw. I'm so used to
> > work with such guarantees that I forgot to be explicit about it.
> > (I said 'transfer' instead of 'copy' because I have move-semantics in my
> > head :-)
>
> I understand. However, this sort of assumption is a poor one for generic
> components.
>
OK.

> > > > does the technique of reserving storage always provide the basic
> > > guarantee?
> > >
> > > Clearly not.
> > >
> > How about in the case where copy-ctor/move don't throw.
>
> Depending on how much of the internal state is visible from the outside,
it
> might even give the strong guarantee.
>
I see.

> > In some applications, like mine, this is almost always the case.
> > If an object can throw when copied, I use handle/body and 'clone()' so
> that
> > copy/assignment (of the handle) never throws, and if I need a 'real'
copy
> I
> > always write:
> > handle new_object = old_object->clone(); // can throw.
> >
> > So I'm usually left with only contaier-reallocations to worry about.
>
> That's generally expensive, but whatever floats your boat...
>
It's a bit expensive, true, and definitely more verbose.
It just helps me to know that the copy does not provide the strong-guarantee
and so the operation will affect the exception behavior of the block doing
it.
Of course, there are other less-intrusive idioms to achieve similar
effects... I'm becoming aware of them.

--
Fernando Cacciola