Re: Access to tagged type parameters

[Ted Dennison<dennison@telepath.com>]

In article <9ljud5$ck8$1@houston.jhuapl.edu>, Jonathan DeSena says...
>
>Ted Dennison wrote:
>> FWIW, GreenHills tags the same line with the following error:
>> LRM:3.10.2(28), The prefix to 'ACCESS shall not be statically deeper than
>> that of the expected type, Continuing
>> 
>So, does that mean the original quote is incorrect, or just that some 
>compilers do not impliment it correctly? 

I think the Gnat compiler is catching the same error for the same reason, but is
attempting to give it a short understandable message, rather than refer you to
one of the most obtuse sections of the LRM.

What I'm not sure about is *why* this is illegal, but if two compilers based on
two very different front ends flag it, I suspect it is a perfectly valid error.
Hopefully a good language-lawyer can come and explain it for us...

>> Another possibility is to use the "access" parameter mode instead of "in
>> out". In that case, the accessability rules seem to behave as I would
>> expect.
>Unfortunately, the reason I want to do this is to be able to add the passed 
>in tagged type, say type A_Type, to a routine which will add it's access 
>value to an array of access values, say  A_Access_Type.  Thus I WANT to be 

That's fine. You'd just change the parameter type to "access", the assignment to
"B_Access := A_Access_Type(B);", the procedure call to "A_Test(C'Access);", and
add an "aliased" to the declaration of B. I tried that with Gnat and it compiled
and ran successfully.

>I suppose 'Unchecked_Access might do the trick, but I don't know enough to 
>know where the pitfalls of using it are. Also, this seems overly 
>complicated just because of using a tagged type.

Since its totally unchecked, the pitfals are the ones you were willing to accept
when you tried to do the assignment in the first place: There is no guarantee
that the object that it points to will exist, unless you have structured your
code in such a way as to ensure it. If you find that you need Unchecked_Access,
you should certianly take a step back and see if that is the case. But you
shouldn't shy away from using it entirely, any more than a C user would shy away
from using "&" entirely. Sometimes it is nessecary. 

>I tried to remove as many access types as possible to simplify matters, but 
>because I am using a recursive type, they are required (won't compile 
>without them).  Because of Ada's strong typing (a good thing, I agree), 
>once I use access types, they seem to proliferate throughout the package.

If you want to create hetrogenious data structures for dynamic disptaching, they
are required. That's kind of an unfortunate departure from Ada's philosophy of
never requiring pointers, but there it is.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com