Re: How do I get this to work??

[Matthew Heaney <matthew_heaney@acm.org>]

warwicks@telusplanet.net (Chris Warwick) writes:

> I will admit some guilt at being a "reformed" C programmer... But, what I find 
> odd is the concept that pointing to an object on the "stack" is poor practice. 

Maybe what Robert is saying is that, given a choice between

1) declaring an object (on the stack) as aliased, taking the 'Access of
   that aliased object, and passing that access value to an external
   subprogram; or

2) declaring an object (on the stack), without declaring it as aliased,
   and passing that object directly, as an in out parameter passed by
   reference;

that 2) is that preferred alternative.

> Even from my Ada83 days, the only "safe" way to do dynamic memory
> allocation was though the use of local variables on the stack. If I
> understand this concept, then the view is that it is better to point
> to a newly allocated buffer, then it is to point to a procedure's
> local variable.

I think this was the thinking by the Ada83 designers.  They were trying
desperately to avoid the possibility of dangling references.

I didn't especially like this "feature" of Ada83.  I think a language
should make it difficult for me to do something potentially error-prone
(like take the address of a stack object), but not impossible.  The
language should get the hell out of my way.

> Given that most Ada compilers have no way to deallocate memory, I seem
> to be trading the potential for a pointer to exist past the life of
> the allocated memory for a program continously allocates memory...

I don't think anyone is advocating that you create memory leaks.

Although officially all Unchecked_Conversion has to do is set the
pointer passed in to null, without actually deallocating any memory, in
practice UC really does reclaim memory.  It's just like free().  So it
is untrue that "most Ada compilers have no way to deallocate memory."

(Because the terms "heap" and "deallocate memory" aren't formally
specifiable, there's nothing the RM can do except specify external
behavior, as in "set the pointer to null.")

The moral of the story is that, in general, when you have a choice,
don't manipulate references ("pointers") directly.  The language
mandates the argument passing mechanism (by val vs by ref) for types
passed to a subprogram having a C convention, so the idea is to let the
compiler generate the reference ("address") automatically.

Now if we could only declare in out args for "value-returning
subprograms"...
-- 
Those who believe in the supernatural should be required to learn
computer programming.  This would force them to discover that things
which appear at first to be completely mysterious and incomprehensible,
in fact have a logical (and usually simple) explanation.  --J.B.R. Yant