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: 103376,109419a9e4966aaf X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Heap Memory Management Question(s) Date: 04 Apr 2006 11:06:21 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <443242EC.2060603@gmx.de> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1144163182 15366 192.74.137.71 (4 Apr 2006 15:06:22 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 4 Apr 2006 15:06:22 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:3717 Date: 2006-04-04T11:06:21-04:00 List-Id: Florian Liekweg writes: > Hi, everybody, > > in the last few days, I've been thumping through the LRMs for both Ada > 83 and Ada 95. You might want to take a look at the (draft) Ada 2005 manual, which is available somewhere on www.adaic.com. Also, John Barnes' book has a nice discussion of access types and storage pools and whatnot. > First off, I understand that Ada provides both explicit deallocation > of heap objects, and garbage collection. The designers of Ada 83 apparently expected GC to be supported, but most compilers do not support GC. However, I believe you can use the BDW conservative GC with Ada. > Now, the LRM for Ada83 defines in \S 3.8 (Access Types), that all > objects bound to variables of a particular access type form an > implicit collection, and objects belonging to different collections > are disjoint (which is actually a nice feature in comparison to > e.g. C++, where for every type T, there is only one pointer type, T*, > which is visible anywhere in the program, so that any variable "T* > foo" can point to any object allocated at any "new T ()" statement, > and any class T object can be manipulated anywhere in the program). "Disjoint collections" sounds like a nice feature, but I think it is hardly ever useful. Usually, one declares a single access type for each designated type. Having a name for it is just a nuisance -- the C way is preferable in this regard. Ada 2005 allows anonymous access types almost anywhere -- "Foo: access T;" is sort of like "T* foo" in C. In Ada 83, access types could only point at heap objects. Ada 95 added "access all", which allows pointing at declared objects, and allows conversion from any other access type with the right designated type -- i.e. crossing collections. I removed the term "collection" from the Ada 95 RM, because I didn't think it was all that useful. But the concept is still there -- access types without the "all" behave as in Ada 83. > But is there any way to use this concept for managing the heap memory > of the objects of a particular collection? Clearly, given some type T > and "type T_ptr is access T", when the definition of T_ptr goes out of > scope, there is no way of accessing objects of the collection of > T_ptr, so, at first sight, a clever compiler could deallocate these > objects. Some compilers do that. Most do not. I don't think it's a good idea, especially now that we have storage pools. In my experience, approximately zero access types are nested inside procedures anyway. >... Then again, isn't it possible to have some static (i.e., > global) variable of type T_ptr which references a T object while the > T_ptr is left momentarily, and until it is entered again? No. In Ada 83, if T_Ptr is local to a procedure, it's not visible outside, so you can't declare variables of that type outside. In Ada 95, you can use general access types (the "access all" kind) to create such dangling pointers. However, you have to say 'Unchecked_Access to do so, which makes it harder to do by accident. You can use finalization to clean up such potentially-dangling pointers. I'm not sure what you mean by "left momentarily", but you can't create a pointer to a local collection, return from the procedure, then reenter the procedure and expect it to point to the same thing! If you dereference a dangling pointer, your program will behave in an unpredictable manner. >... This would > imply that the lifetime of T objects belonging to the T_ptr collection > is not bracketed by the visibility of the definition of T_ptr. The lifetime of a local collection is local. > Then, Ada 95 seems to have abandoned the concept of collections > entirely --- even the word itself cannot be found neither in the LRM > nor in the rationale (except when it refers to "garbage collection"). > It also introduces the concept of Storage_Pools which are managed by > user-written code, which /could/ be taken to mean that any compiler > optimisations that were done on collections were not satisfactory. Is > there any truth to that? I suppose you could put it that way. There are hundreds of reasonable ways of managing heap memory, none of which is best for all purposes. Therefore, whatever method the compiler provides will not be best for some programs. That's why we added storage pools -- the user can then define the heap-management strategy. They can deallocate objects en masse when leaving a procedure, if that's appropriate. Most programs can just use the default storage pool provided by the compiler. - Bob