Re: put of access type

[Adam Beneschan <adam@irvine.com>]

On Aug 20, 1:05 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Dennis Lee Bieber <wlfr...@ix.netcom.com> writes:
>
> > On Tue, 18 Aug 2009 23:36:15 -0400, Rob Solomon
> > <use...@drrob1-noreply.com> declaimed the following in comp.lang.ada:
>
> >> The only way I know to see the results of my playing is to output
> >> them.
>
> >    And what meaning would some address from either the stack or a heap
> > have? You can't modify them -- Ada's access types are so heavily
> > controlled they are basically black boxes with no inherent meaning.
>
> Yes, but seeing the actual values helps the learning process.

I don't see how.  If the goal is to learn to use Ada to write more-or-
less "normal" programs, then there's no particular value in seeing the
actual "value" of an access object, as opposing to simply "knowing"
that a non-null access object designates some other object.  In fact,
I'd argue the opposite: It helps the learning process to force oneself
to think of access values as "black boxes" that designate some other
object, because it helps one get in the mind-set of thinking in terms
of abstractions that you can use without knowing how they're
implemented.  And Ada is definitely a language that allows and
encourages a programmer to think that way---it's not perfect, but it's
pretty good.  I think that C programmers in particular who are trying
to learn Ada probably need this sort of mental discipline to change
the way they think about programming.  I've seen too much Ada code
written by C programmers who didn't make this change.  The code is
terrible---very difficult to read and maintain.  I don't know Modula-2
at all, and I thought it was better than C at allowing an
"abstraction" approach to programming; but from Rob's comment that a
pointer is assignment-compatible with System.Address, apparently it
isn't better, at least in that one aspect.

However, if the goal is to learn Ada to do systems programming, or
write other programs where it's *necessary* to do low-level meddling
like Unchecked_Conversion and that sort of thing, then I'd say you're
right.


> A : aliased Interfaces.Unsigned_32;
> B : aliased Interfaces.Unsigned_32;
>
> begin
>     Put (To_Integer (A'access));
>     Put (To_Integer (B'access));
>
> The results should be 4 bytes apart.

Ummm... why?  What rule in Ada says that the compiler has to put A and
B next to each other?

                                      -- Adam