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,1042f393323e22da
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Any research putting c above ada?
Date: 1997/05/08
Message-ID: <EACHUS.97May8153339@spectre.mitre.org>#1/1
X-Deja-AN: 240271726
References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu>
 <5ijb0o$ajc@ns1.sw-eng.falls-church.va.us>
 <334d3da5.14386594@aplcen.apl.jhu.edu>
 <2senchydgk.fsf@hpodid2.eurocontrol.fr> <5im3an$3dv@bcrkh13.bnr.ca>
 <2sybamvslk.fsf@hpodid2.eurocontrol.fr>
 <5ius80$1nr8@newssvr01-int.news.prodigy.com> <335ae79e.55ed@dynamite.com.au>
 <5jde9l$u8q@newssvr01-int.news.prodigy.com> <33643f1f.0@news2.maynick.com.au>
 <5k3fma$126a@newssvr01-int.news.prodigy.com>
 <336eda35.0@news2.maynick.com.au>
 <DD2AAB2177A8804B.CD3498B59571A5AA.712C11BECD11BCCC@library-proxy.airnews.net>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1997-05-08T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <DD2AAB2177A8804B.CD3498B59571A5AA.712C11BECD11BCCC@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

  > How does Ada help you avoid the problem of managing dynamically
  > allocated memory?

   First, many of the calls to malloc and free in C and C++ just go
away, since a lot of the allocations that have to be done on the heap
in C end up on the stack in Ada.  The most obvious example is that a
function can return an unconstrained array without the programmer
putting it in the heap.  The compiler may or may not use the
heap--most prefer to play games with the stack or to have two
stacks--but that is an implementation detail, and there is no
(programmer) risk of memory leaks or invalid pointers.

   Second, another bunch of calls goes away because you can have
objects of arbitrary size on the stack.  Once allocated, the size is
set, but that is what is usually wanted:

     Buffer: String := My_IO.Get(Some_Terminal);

   The size of the buffer is determined by the return value of Get.
You can assign to Buffer if you want, but you can't change the size.

   Third, there is a garbage collected, or somehow managed, dynamic
string type in Ada:

    use Ada.Strings.Unbounded;
    ...
    Buffer: Unbounded_String;
    ...
    while not My_IO.End_Of_File(Foo) loop
      Buffer := To_Unbounded_String(My_IO.Get_Line(Foo));
       ....
    end loop;

    In this example, the length of Buffer changes each time through
the loop, but again the programmer doesn't have to manage any pointers,
allocation, or deallocation.

    If you get this far, and still can't solve your problem, there are
hundreds of abstract data types that do their own storage management
using package Finalization so that users never need worry.

    So the only poor sods who ever have to worry about managing memory
in Ada 95 are probably the students taking a data structures course in
Ada, and people like me who build ADTs to share.  But I have gotten to
the point where the management of memory is about sixteenth on the
list of things to consider when implementing an abstraction--it really
is that easy to do things so that the memory management is invisible
to the user.  Of course some of the results are a bit surprising--I
often find that the type with the (implicitly called) Finalize
procedure is not the type which is allocated on the heap, but that is
and should be an implementation detail.  Of course, for Ada 0y, I may
propose Controlled access types, just to clean up some of the
notation, but that just saves a few characters per reference in the
source code. ;-)



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...