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: clines@delete_this.airmail.net (Kevin Cline) Subject: Re: Any research putting c above ada? Date: 1997/05/09 Message-ID: <208C9C61CA05C32B.65D82DC950AAA33A.D68E7B27EB42E98A@library-proxy.airnews.net>#1/1 X-Deja-AN: 240382814 References: X-Orig-Message-ID: <3373aa6b.1212359@news.airmail.net> Organization: INTERNET AMERICA X-A-Notice: References line has been trimmed due to 512 byte limitation NNTP-Proxy-Relay: library.airnews.net Newsgroups: comp.lang.ada Date: 1997-05-09T00:00:00+00:00 List-Id: eachus@spectre.mitre.org (Robert I. Eachus) wrote: >In article 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. The last time I tried this, the compiler copied the entire array when the function returned. That much overhead was completely unexpected, and in my case, also unacceptable. I don't like languages that hide large amounts of overhead in simple operations. It's okay if they let me hide it through operator overloading. But I don't enjoy finding out when I port my program that a function return is massively wasteful. In C++, you would solve this problem by passing a reference to a container. > 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. No, but he will probably pay for the string to be copied twice, once upon return from My_IO.Get_Line, and once in the conversion. > 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. C++ is no different. Allocation and deallocation can always be encapsulated. What actually happens is that mediocre C++ programmers don't bother to encapsulate. In an Ada shop, mediocre programmers simply avoid dynamic allocation, use lots of arrays, and hope they are big enough. For embedded systems, that's usually a reasonable approach. For desktop applications, it isn't.