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,aa968038a51ee866 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Q: Ada.Unchecked_Deallocation Date: 1996/07/12 Message-ID: #1/1 X-Deja-AN: 168757883 references: <31E5D4D1.11DB36E1@jinx.sckans.edu> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-12T00:00:00+00:00 List-Id: David Morton says "If something is created dynamically with new, is it necessary to deallocate it with Ada.Unchecked_Deallocation, or will it be removed from the heap space when the program exits? From the "C" world, I've always been taught to clean up after myself... is this necessary? It seems that usually, "Unchecked" anything in Ada is bad... " The entire heap goes away when a program exits anyway in any implementation that you are likely to run into (this is why in C++ destructors are not applied to globally allocated objects on the heap, it is assumed that destructors are usualy used for storage allocation and so there is no point in calling them at the outer level (*) Unchecked_Deallocation is not *bad*, if it was bad it would not be in the language. It merely is unchecked, that's all. This means that the checking that is needed is not automatic, and so you have to program it, not such a terrible thing. In other words, when you use UD, you promise to behave yourself (i.e. not to free things that were not allocated, not to free things more than once, and not to reference things after they are freed), and if you don't behave yourself, your program may malfunciton, possibly seriously. Yes, we prefer to stay away from unchecked stuff where possible, but if you need it, then it is not bad, it is good! If you need to clean up storage BEFORE the end of your program, then you must use UD and be careful (the finalization semantics of Ada 95, which are analogous to the destructors of Ada 95) are an excellent way of helping yourself to be careful. However, cleaning up at the end of the program is unnecessary (I can't believe any C program would actually go to the trouble of freeing globally allocated memory before exiting -- are you really saying you do this???) (*) In Ada, finalization routines *are* called for globally allocated objects on final program termination, and you can imagine cases (releasing operating systems locks) where this semantics is critical. However, in Ada 95, as in C++, 99% of the time finalization is used only for freeing storage, and not only is it a waste of time to call the finalization routines at the outer level, but much worse, you waste time and space on the initial allocation of such objects setting up the data structures to ensure that you can do these useless finalize calls. In a garbage collected environment, it is sily to do finalization calls at any level if all they do is to free storage (and indeed a perfectly reasonable implementation of Unchecked_Deallocatoin in a garbage collected environment is to completely ignore all calls to it). So the situation is even worse. We talked at one point with Tuck about a pragma that would be applied to a type something like Finalization_Is_Used_Only_For_Freeing_Storage (type); (well we need a better name :-) the effect would be to simply ignore finalize calls at the outer level, or, in the case of a GC Ada 95, to ignore all finalize calls for the type. Thoughs?