Re: Ada 95 constructors on limited types

["Randy Brukardt" <randy@rrsoftware.com>]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1379898.fuxZSb5qdF@linux1.krischik.com...
...
> > type Class_Access is access all Class'Class;
>
> Do you need that "all"? Because because the "all" does not come for free -
> there are some penalties.

Say what? The only penalty in using "all" is that a few very dubious
constructs are illegal (they're legal for pool-specific types in order to
maintain Ada 83 compatibility. Indeed, for Janus/Ada, it actually makes the
code better (because we generate code that checks that pool-specific access
values belong to their pool when they are dereferenced; for obvious reasons
we can't do that for "all" or for user-defined pools).

It also makes your code better as it allows you to avoid using allocators at
all.

Of course the very best solution is to avoid the access type altogether,
which you may be able to do by using one of the containers libraries.

> Read:
>
>
http://en.wikibooks.org/wiki/Ada_Programming/Types/access#Access_vs._access_all

The claim that additional checks may be needed on the deference of an
"access all" is completely bogus; Janus/Ada always does *less* run-time
checking for "access all" than "access". While it's probably true that for
most compilers that it is the same, I can't think of any reason that it
would be more -- at least not on typical machines. (There might be
additional checks required because of the designated type, but those would
be the same for access and access all.) One could imagine a super-safe Ada
system that did extra checks to prevent problems with
Unchecked_Deallocation, but that would not have any cost for dereferencing.

The argument about safety is certainly true, but it may be misleading:
Unchecked_Deallocation is always dangerous if misused. It is just as easy to
deallocate a pool-specific object twice, and just as dangerous as
deallocating a stack object. The advantage of "access all" is that you may
not need to use Unchecked_Deallocation at all.

Moral: if you have (or may have) a valid reason to store an 'Access or
'Unchecked_Access into an access type, then use "access all" and don't worry
about it. If not, the mantra of "least privilege" suggests that the "all"
should be left out (don't enable capabilities that you are not going to
use), but it is hardly the level of concern that it should cause someone to
complain about it's use in an example program.

OTOH, the advice about avoiding access altogether for parameters, and
especially anonymous access, is spot-on.

                                                Randy.