Re: Controlled types and exception safety

[Maciej Sobczak <no.spam@no.spam.com>]

Dmitry A. Kazakov wrote:

>>>ARM 7.6.1 reads: "It is a bounded error for a call on Finalize or Adjust to
>>>propagate an exception.

>>OK, that brings some light, but does not solve my problem. :)

> Which is not solvable. [...]
> Now you
> are sitting in a rocket, a user-defined constructor has just turned on the
> ignition, and oops, you notice that you have left your hat at home...

Now I'm copying a Stack object, a user-defined Finalize dutifully 
cleaned up the "old" state, the Adjust started to duplicate the 
structure and it notices that there is not enough memory to do this...

The analogy with a rocket and a hat does not fit, unless you want me to 
believe that Ada is good enough for rockets, but not good enough for 
stacks. ;)

>>When I said "copy" above (C++), I meant create a new object as a copy. 
>>This involves copy constructor. The point is that this new object is 
>>*separate* from the destination object (from what's on the left side of 
>>assignment operator),
> 
> 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.

> 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 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).


>>The assignment is defined as Finalize + Bitwise copy + Adjust.
>>And it's the fact that Finalize comes first that bothers me.
> 
> Me too, but exception-safety is irrelevant to the issue. If Ada should ever
> have user-defined constructors and assignment (because Ada.Finalization is
> not), then I would really like to have an access to the left part of the
> assignment. IMO, the model could be:
> 
> 1. Compiler-generated assignment is generated as Finalize +
> Copy-constructor.

No. Copy-constructor might fail and you've already sold your house.
For exception safety, it should be the other way round.

> 2. User-defined assignment can override it. However, there are many tough
> problems. The assignment should be able to change the constraints (i.e.
> bounds, discriminants, tags.) It should be composable against aggregation.
> It should have access to the left part, but also be able to override it
> in-place.
> 
> AFAIK, there is no language which does it right.

What's wrong with the example I provided in my previous post?


>>Note that in the example above there is no "partial completion". On the 
>>contrary - either the operation completes successfully or it fails 
>>*wihout* modifying anything. Moreover, the scheme does not force me to 
>>ignore the error nor anything like this, I can let it go to the place 
>>where there's enough context to really handle it.
> 
> No, as I tried to explain above, it just moves the problem to construction
> of a temporal object.

Which is exactly what is needed. If it fails, it can be rolled-back 
without touching the original left object.
Note that we are talking about copyable objects and not all objects need 
to be copyable in the first place. Stacks and other containers deal with 
memory structures and they *are* copyable, and the failures in their 
copy constructors are easy to deal with in the sense that rolling back 
the constructor does not influence neither the assignee nor the exception.

>>Is it possible to have assignment with strong exception guarantee?
> 
> For a user-defined assignment the answer is no, or it is a halting problem.
> For generated assignments it depends on whether its components are
> reversible.

The problem is that whenever I think that a type should be Controlled, 
it is because of these two things (always):
1. The type should be copyable (again, not all types should).
2. The default copy behavior is bad, because it leads to state sharing 
or other anomalies.

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?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/