Re: Controlled types and exception safety

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 01 Dec 2005 11:46:42 +0100, Maciej Sobczak wrote:

> Dmitry A. Kazakov wrote:
> 
>> 1. This changes little. Consider an exception raised while construction of
>> the copy. The copy is corrupt. Both to destruct or to just deallocate it
>> could be wrong.
> 
> This changes a lot. I *know* how to deal with exceptions in 
> constructors, especially if their only effect is to build structures in 
> memory (and that applies to Stack in particular). Note that when the 
> constructor throws/raises, the object is considered to be never created 
> and its destructor is therefore never called.

I.e. whatever side effects the failed constructor has caused, they will
persist. The problem is not in finalization of the target. The problem is
in the system state = whether objects invariants hold between their
construction and finalization.

>> 2. User-defined constructor as a concept is useless if I cannot construct
>> in-place. Consider construction of non-movable objects containing self
>> references or bound to definite memory locations.
> 
> You can do this in constructors. But *copy* constructors are for copying 
> objects

Not quite. They are for constructing objects. Copying is allocation +
construction.

> and not all objects need to be copyable in the first place. I 
> don't expect objects bound to definite memory locations to be copyable.
> Stacks can be copyable (all standard containers are, for that matter).

Graph of linked nodes is a counter example, it cannot be moved, but can be
copied.

[...]
> What's wrong with the example I provided in my previous post?
[...]
> Which is exactly what is needed. If it fails, it can be rolled-back 
> without touching the original left object.

As I said, in my view it has little to do with exception safety. What you
actually wish is to have access to the left side of assignment. Controlled
types do not provide this functionality. End of story.

As for the pattern:

1. clone implementation;
2. copy reference;
3. collect unused object

which you posed as an example. It cannot be disguised as ":=". You have to
name it otherwise, like "Replace". [And neither will be double dispatching
too, which is much worse thing, if you are looking something really bad.
(:-))]

I don't count the pattern for a big deal, because in most cases it is a
*bad* pattern. It is bad because it overloads ":=" with semantics the
latter should not have (i.e. non-trivial memory allocation.) and it has a
heavy performance penalty. I'm using reference copy postponing cloning for
later, on demand. In my component library Stack is a limited type. Set is
indeed copyable. It uses the reference semantics, so ":=" just increments
the reference count.

> The difficult part is that in *all* cases that I've seen or written (in 
> C++), it was not possible to guarantee that the duplication of state can 
> be performed without errors. This certainly applies to all types that 
> have dynamic memory structures behind them, starting from innocent 
> unbounded string. Ada has unbounded string, recommended on this group in 
> various contexts. How does it dolve this problem? Does it?

I think Randy has answered that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de