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,d539bdb3eb59727e,start X-Google-Attributes: gid103376,public From: "Stanley R. Allen" Subject: Unneeded storage pool init/final Date: 1998/04/22 Message-ID: <353E2A1A.167E@hso.link.com>#1/1 X-Deja-AN: 346703193 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Organization: NASA, Kennedy Space Center Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-04-22T00:00:00+00:00 List-Id: Does anyone know? Given this package spec and body: ------------- pack1.ads ------------------ with Ada.Finalization; use Ada.Finalization; package Pack1 is type List is limited private; procedure Create (L : in out List; Value: Integer); function Equal (A, B : List) return Boolean; private type List is new Limited_Controlled with record Num_Elements : Integer; end record; type List_Pointer is access all List; end Pack1; ------------- pack1.adb --------------- package body Pack1 is procedure Create (L : in out List; Value : Integer) is begin L.Num_Elements := Value; end Create; function Equal (A, B : List) return Boolean is type Const_Lp is access constant List; begin return Const_Lp '(A'access) = B'access or else A.Num_Elements = B.Num_Elements; end Equal; end Pack1; ---------------------------------------- My understanding is that the declaration of Const_Lp will cause a storage pool to be initialized and finalized every time Equal is executed, even though no allocation is performed, and the type is only needed for the qualified expression used in the return statement. At least, that is how I understand things based on the following output from the gnat compiler (using gcc -c -gnatdg pack1.adb): ------------------------------------------- with system.tasking_soft_links; package body pack1 is procedure create (l : in out list; value : integer) is begin l.num_elements := value; return; end create; function equal (a : list; b : list) return boolean is F1b : finalizable_ptr := null; procedure _clean is begin abort_defer.all; finalize_list (F1b); abort_undefer.all; return; end _clean; begin type const_lp is access constant list; freeze const_lp [ const_lpL : list_controller; _init_proc (const_lpL); attach_to_final_list (F1b, finalizable?(const_lpL), 1); initialize (const_lpL); ] return const_lp'(a'access) = b'access or else a.num_elements = b.num_elements; at end _clean; end equal; end pack1; pack1_E := true; ---------------------------------------------- So, my questions are: Is a pool being created by the declaration of Const_Lp? Is it the creation of the pool which causes GNAT to perform initialization/finalization in the implicit code shown above (because Root_Storage_Pool is based on Ada.Finalization.Limited_Controlled)? Is there a way to eliminate this implicit code? (After all, it is overkill for the purpose for which type Const_Lp exists, namely to give me the ability to ask if a'access=b'access). (I know that I can move the declaration of Const_Lp out to the library level and change the 'access references to 'unchecked_access; this is good as a workaround, but it makes Const_Lp more visible than I like.) These two approaches don't achieve the desired effect (at least as far as GNAT is concerned, because I still see the implicit code using gnat -c -gnatdg): for Const_Lp'Storage_Size use 0; for Const_Lp'Storage_Pool use List_Pointer'Storage_Pool; Either these are not valid ways of eliminating the pool or its init/final code, or the GNAT compiler doesn't optimize out the init/final code in these cases. If better optimization would solve the problem, then is it possible for a compiler to recognize that no allocation is taking place in the original code, and use that knowledge to optimize away the init/final code, or is there some case in the Ada rules which makes this impossible? Am I missing something obvious? -- Stanley Allen mailto:s_allen@hso.link.com