Talk:Ada Programming/Types/access

Page Structure
I find the separation of "Declaring access types" and "Using access types" unfortunate. I think explaining in 8 subchapters how to define access types and only then in the next chapter explain how to create objects and how to dereference does not make understanding easy.

But before incorporating chapter 2 in chapter 1, I want to know what others think about this.

2010-01-08 CKWG

.all not explained
The page uses .all and has a discussion of its advantages and disadvantages, but nowhere says what it actually means or does. For a "tutorial" stle wikibook page it would be helpful to explain .all or link to an explanation. (I'm a newbie, so I can't do it myself. I came here looking to solve a problem, and .all would have been the answer, but the explanation wasn't here).

--Digitig (talk) 13:23, 12 March 2009 (UTC)


 * I've added the explanation. I hope it helps, otherwise, please request further clarification. -- ManuelGR (talk) 22:28, 12 March 2009 (UTC)

access all vs. access
Reordered access all vs. access. See Randy Brukardt in CLA:

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

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.

"may not"
Under http://en.wikibooks.org/wiki/Ada_Programming/Types/access#Pool_access the following sentence is found: "It may not point to a stack or library level (static) object or an object in a different storage pool."

How should someone interpret "may not"? Given that context, is it the same like "must not"?


 * It should say "cannot" since these access types can only point to objects reserved from their corresponding storage pool. This is a constraint imposed by the language on these types. ManuelGR (talk) 22:05, 1 September 2008 (UTC)