Re: Allocators and exceptions

[Adam Beneschan <adam@irvine.com>]

On Sep 12, 5:22 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 11 Wrz, 23:56, Adam Beneschan <a...@irvine.com> wrote:
>
> > OK, I think I have one.  GNAT compiles and runs it, although I haven't
> > checked the language rules carefully to make sure it's legal.
>
> Without checking the language rules carefully, I think this is a legal
> program demonstrating artificially broken design.
>
> Consider that there is no exception and instead you call
> Unchecked_Deallocation after successfully creating the object.
> The P pointer will be dangling.
>
> So what is your example proving? That we can make dangling pointers in
> Ada? This is already known.

You can create dangling pointers and do all sorts of other bad stuff
by using "Unchecked" features like Unchecked_Deallocation, and other
things like 'Address clauses.  These are documented in the manual, and
it's pointed out that the user needs to know what they're doing or
else the result could be erroneous.  But the language shouldn't be
adding dangerous stuff like that automatically.
Unchecked_Deallocation is called "Unchecked" for a very good reason,
to remind those who use the routine that it could lead to trouble.
But the language can't start doing such unchecked stuff itself
automatically.

Now, I'm aware that I used an Unchecked thing ('Unchecked_Access) in
my example.  So far, I haven't been able to create an example that
doesn't.  But I'd want a *proof* that it's impossible for the
automatic deallocation you're asking for could not create a dangling
pointer in the absence of Unchecked or other dangerous features, and
I'm not yet convinced.  (And your earlier statement that  "the object
simply does not exist" falls several miles short of a proof, and my
example proves that that is wrong anyway, because the object does
exist temporarily.)

But you seem to be suggesting that the language should just do the
"right thing" anyway (i.e. deallocate the object), and if a certain
combination of legal features leads to a disaster like a dangling
pointer, you throw up your hands and blame it on a broken design.
That's the C++ way, not the Ada way.  In Ada, safety is important.  We
try to make sure programs can't cause this sort of problem unless the
user deliberately does something that is known to be dangerous.

By the way, although I think having the language deallocate the object
automatically is a bad idea, I do sympathize with the problem that
it's impossible to get a hold of the access value that was already
allocated so that you can do an Unchecked_Deallocation yourself.  None
of the workarounds seem all that good.  Unfortunately, I can't think
of a good way to add this to the language.

                        -- Adam