Re: Safety of the Booch Ada 95 Components

[herwin@gmu.edu (Harry Erwin)]

Matthew Heaney <matthew_heaney@acm.org> wrote:

> In article <t790326901.fsf@calumny.jyacc.com> , Hyman Rosen 
> <hymie@prolifics.com>  wrote:
> 
> > In C++, class objects are copied through a class method called the
> > copy-constructor, to allow for resource control.
> 
> Data structures (in Ada95) are written as generics that accept the
> container item as a nonlimited generic formal private type:
> 
> generic
>   type Item_Type is private;
> package Stacks is ...;
> 
> The "copy constructor" in Ada95 is just the assignment operator that
> comes with Item_Type.  Typically, the client of the assignment operator
> (here, the implementation of the Copy operation for stack types) assumes
> that assignment doesn't raise an exception.
> 
> We make this assumption per the "design-by-contract" model.  If you give
> me an assignment operator that doesn't work, and it raises an exception
> (say), then yes, that would leave the target object in an inconsistent
> state.

Such exceptions in C++ are thrown if resources necessary for creating
the object are not available. These are most commonly memory, but
construction is the idiom used _in_general_ for resource management.
Also, in C++, termination semantics are default for exception handling.

> 
> If you don't like that, then don't give me a broken assignment operator.

A deep copy of a pointer data structure may require more memory than is
available. Similarly for a dynamic data structure. In C++, the
constructor throws a bad_alloc exception, and the class instance is
cleaned up. Not broken at all.

> 
> > If an exception is thrown during copy-construction of one of the
> > elements, it's possible that the target data structure may be left in an
> > invalid state.
> 
> I suppose if you don't trust your client's assignment operator, then you
> could make a copy of the target object, clear the target, and then do
> the copy.  If there's an error during assignment, then you use the copy
> of the target to restore the target back to its original state, and then
> reraise the exception.

template <typename T>
C<T>& operator= (const C(T)& c)
{
    if(this==&c) return *this; // for efficiency, not required
    C<T> temp(c); // may throw
    swap(temp,this); // swaps the guts, does not throw
    return *this; // does not throw
} // temp is deleted when it goes out of scope. does not throw

(per Sutter, 2000)

This idiom supports commit/rollback semantics.

> 
> (But then again, I don't know how you would even implement this.  How do
> you make a copy of the target, if you can't trust the copy constructor
> for items?)
> 
> But this is an awfully heavy way to implement a Copy operation for a
> data structure.  The canonical implementation of a Copy operation should
> choose the more efficient implementation, which assumes that assignment
> works (again, per DBC).
> 
> If you don't like the canonical Copy, then just extend the abstraction
> with a child operation implemented using the pessimistic algorithm
> (which I'm not convinced is even implementable).
> 
> --

-- 
Harry Erwin, PhD, <http://mason.gmu.edu/~herwin>