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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,3ef3e78eacf6f938 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!s31g2000yqs.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: A few Ada questions Date: Thu, 23 Jul 2009 17:28:52 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: NNTP-Posting-Host: 88.170.86.208 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1248395333 8395 127.0.0.1 (24 Jul 2009 00:28:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 24 Jul 2009 00:28:53 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s31g2000yqs.googlegroups.com; posting-host=88.170.86.208; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009061208 Iceweasel/3.0.9 (Debian-3.0.9-1),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:7299 Date: 2009-07-23T17:28:52-07:00 List-Id: Andrea Taverna wrote on comp.lang.ada: > I've got a few questions about Ada, generated from discussion > . > > I apologize for my annoying newbieness :D > > On 18 Lug, 17:50, Ludovic Brenta wrote: > > > > > Andrea Taverna wrote: > > > [...] > > > > So I have considered these alternatives: FreePascal, Eiffel, Ada and > > > Modula-3 > [....] > > > As for memory management (requirement 4), I heard there are different > > > takes on the matter: > > > =A0(a) Ada uses dynamic stack allocation a lot, and in a transparent = way, > > > reducing the need of manual management (MM) > > > =A0(b) Ada libraries adopt idioms that further simplifies MM issues > > > =A0(c) Conservative garbage collectors such as Bohem's can be used wi= th > > > Ada, and they are supposed to work "better" with Ada than with unsafe > > > languages such as C and C++ > > > I have to add: > > =A0 (d) controlled types allow you to control allocation and > > deallocation without a garbage collector. > > > > So can MM be said to be easier in Ada than in C? I hope Ada-ers will > > > mercifully shed some light on the issue. > > > Yes, MM is definitely easier in Ada than in C; my experience with > > Java's garbage collector is that (a) you never learn to manage memory, > > and (b) is is very easy to run out of memory and get the infamous > > OutOfMemoryError. =A0That has never happened to me in Ada, simply > > because Ada forces me to think about this problem. > > > Another reason why Ada is easier than C is because you use pointers > > only for what they were designed: dynamic allocation and > > deallocation. =A0As a consequence, each time you introduce a pointer yo= u > > naturally think about memory management. =A0Contrast this to C where > > simple parameter passing often requires pointers, and with Eiffel or > > Java where everything is a pointer whether you like it or not. > > So I took a deeper look at Ada, and if I'm not mistaken, the MM > support in Ada boils down to > 1) =A0dynamic stack allocation > 2) malloc/free with Unchecked_Allocation > 3) Controlled types that allow you implement constructors and > destructors > 4) Storage pools. > > Apart from (1) and (4), (2) and (3) seem to provide the same > functionality of corresponding C++ features, with the notable > exception that (3) requires tagging the type (*). There are three ways for a type to be controlled: (a) be publicly tagged and extend Ada.Finalization.Controlled; (b) be privately tagged and extend Ada.Finalization.Controlled; (c) be untagged and contain a controlled object. Here is an example of (b): with Ada.Finalization; package P is type T is private; -- primitive operations here private type T is new Ada.Finalization.Controlled with record ... end record; overriding procedure Initialize (This : in out T); overriding procedure Adjust (This : in out T); overriding procedure Finalize (This : in out T); end P; In this situation, clients can use the type and its primitive operations but cannot further extend it (compare to a "final" class in Java). (c) is more advanced, here is an example: package P is type T is private; -- primitive operations here private type Controller (Enclosing : access T) is new Ada.Finalization.Controlled with null record; overriding procedure Initialize (This : in out Controller); overriding procedure Adjust (This : in out Controller); overriding procedure Finalize (This : in out Controller); type T is record -- note: untagged record C : Controller (Enclosing =3D> T'Access); end record; end P; The procedures Initialize, Adjust and Finalize can see their parameter's enclosing object (and therefore all other components) by simply dereferencing This.Enclosing. This pattern is useful for reference counting, among other things. Note that T *may* be tagged for reasons unrelated to controlledness and even extend another type. > As for (4), I couldn't find a practical example of storage pools usage > on the net, I'd really like to see one. > The storage pool I have in mind is the one used in ObjC/Cocoa, i.e. a > storage pool with ref-counted objects. Users can send retain/release > messages to increment/decrement the pool-allocated object's reference > count. In which way does this differ from storage pools in Ada? Ada's storage pools are orthogonal to ref-counted objects. One example is in the GNAT run-time library, see: http://gcc.gnu.org/viewcvs/trunk/gcc/ada/g-debpoo.ads?view=3Dmarkup > I know that they have several benefits compared with pool-less > storage, you can define a homogeneously typed/sized pool improving the > memory management for associated types, and you can implement MM more > easily, but, still, the problems I have with MM (at least in C) are : > - application-specific code is intertwined with MM and vice versa. It > complicates interfaces and hinders reusability. > - objects have a graph-like relationship on which MM depends that > could not be easy to foresee. > - due to the graph relationship, refactoring MM code, which can ease > MM itself, gets harder. > How is Ada supposed to help with this? I guess you'll have to see for yourself how the combination of features listed above helps with the problem. However, you still have to manage memory in Ada; the problem does not magically disappear. > (*) besides, I infer that =A0the visibility checks required for > controlled types exposed at inner levels can be disabled at run-time, > right? This is compiler-specific but, in general, yes. > Finally, I'd have a question about the standard container library. I'm > probably a bit confused since I've recently been hopping from a > language to the other, but I saw that Containers do not define > interfaces and Cursors types are not tagged. > As such I'm not sure whether I can extend new containers from standard > ones, including defining new cursors, while having polymorphic > behaviour. > For example, can I define a linked-list implemented with an array by > deriving a standard container? I'm not an expert on this subject to I'll defer to someone else to enlighten both of us :) HTH -- Ludovic Brenta.