From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,86ec22e070e319c0 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: How do I get this to work?? Date: 1999/01/16 Message-ID: #1/1 X-Deja-AN: 433267475 Sender: matt@mheaney.ni.net References: <76s0dp$1v4$1@nntp3.uunet.ca> <76tbvv$ba5$1@nntp3.uunet.ca> <770ifd$qui$1@goblin.uunet.ca> <771bl9$sla$1@nnrp1.dejanews.com> <77b9cp$5kh$1@nnrp1.dejanews.com> NNTP-Posting-Date: Sat, 16 Jan 1999 00:34:59 PDT Newsgroups: comp.lang.ada Date: 1999-01-16T00:00:00+00:00 List-Id: 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