Re: Weird controlled behavior - Gnat 3.15p NT

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

On Thu, 11 Sep 2003 03:46:56 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> You might say that the above is rubbish. Not at all. It is a design
>> pattern for self-destructing objects.
>
>Not at all. It's a well-known and good pattern, as you say.
>
>> Now imagine what should happen if somebody would allocate
>> Foo on the stack?
>
>Undefined behavior. You are not allowed to do that, and if you do,
>the behavior of the program is unspecifed by the language. (The
>workaround is to make the destructor protected, by the way. Then the
>compiler will prevent such objects from being allocated on the stack,
>because the destructor will be inaccessible.)
>
>If you call a destructor yourself, you must make sure that the
>compiler will not call the destructor again on that object (which in
>fact no longer exists, except as a region of storage with undefined
>contents).

As you see the problem exists. The source is an ability to call a
destructor explicitly and also an ability to call them from the
methods. For many reasons, it is widely used, but it is a very
dangerous and bad thing.

From design point of view, constructor and destructor should be
invisible from the methods. They are not methods and are not a part of
the interface.

That we have to do such things both in Ada and C++ is a deficiency.
However, I cannot say how to avoid it in all cases.

In case of self-destructing objects, there is a safe alternative
solution: smart pointers + object reference counts. Unfortunately both
Ada and C++ do not allow an effective, "coder-friendly", transparent
implementation of smart pointers. For example, Ada has
half-transparent access types, but no user-defined ones, etc.

And do not tell me stories about templates! (:-)) Only a full-blown
ADT may help to solve the problem!

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de