Re: Access to tagged type parameters

[Jonathan DeSena <jonathan.desena@jhuapl.edu>]

Ted Dennison wrote:

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

Ahhh. This does what I want. I had forgotten about type conversions. 
Actually, it is interesting that you can pass an argument of type 
A_Access_Type to a subprogram expecting "access to A_Type," but  the 
converse is illegal; also, you can't equate or assign two variables of 
these two types. 

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

Thanks to all. I was getting very frustrated, but I am better now :)

jtd