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,f92fbb4a0420dd57 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,f92fbb4a0420dd57 X-Google-Attributes: gid109fba,public From: wnewman@netcom.com (Bill Newman) Subject: Re: some questions re. Ada/GNAT from a C++/GCC user Date: 1996/03/29 Message-ID: #1/1 X-Deja-AN: 144872866 sender: wnewman@netcom20.netcom.com references: followup-to: comp.lang.ada,comp.lang.c++ organization: NETCOM On-line Communication Services (408 261-4700 guest) newsgroups: comp.lang.ada,comp.lang.c++ Date: 1996-03-29T00:00:00+00:00 List-Id: Scott Leschke (leschkes@ferret.cig.mot.com) wrote: : wnewman@netcom.com (Bill Newman) writes: : >When I make two different instantiations of a generic package with the : >same arguments, I understand the compiler treats them formally as two : >different packages, which is OK with me. However, I'd appreciate : >knowing the compiler wouldn't actually output two redundant copies of : >the corresponding (identical?) machine code, but instead share the : >code. I saw somewhere that the compiler is given considerable freedom : >to share one instantiation between several arguments if it thinks it's : >appropriate, which is also OK with me. However, I haven't seen any : >guarantee that the compiler won't output redundant copies for : >instantiations with identical arguments. Is there such a guarantee? : My first question would be, why do you want redundant instantiations. : Note that Ada separates instantiation of a generic from use of the : resulting package/subunit. The general rule of thumb to avoid code-bloat : due to duplicate instantiations is to do the instantiation at the library : level and 'with' the resulting package/subunit. I wondered about this because Ada encourages the creation of type distinctions which don't reflect differences in underlying machine representation. In seems as though (mixing C++ template notation with Ada's distinct types represented by machine floating point numbers) Dynamically_Allocated_Stack_Of and Dynamically_Allocated_Stack_Of could share exactly the same underlying code. It would be nice if the compiler would recognize this without me having to figure out some way to implement the templates/generics to make it explicit. Even in C++ (without the option of conveniently making distinct Apples and Oranges types out of e.g. float) this comes up frequently when you use template containers of pointers to things: to the machine, a pointer is a pointer, so the object code tends to be the same regardless of the pointer type. Sometimes in C++ I use a shared implementation for such templates (using void* pointers, and the equivalent of Ada Unchecked_Type_Conversion (?)) but even though the final result can be type-safe if done correctly, it's tedious to make sure that it is, and I'd rather not have to do it in Ada, especially since Ada strongly discourages this sort of thing. If the Ada type system multiplies the number of cases where this would be useful, and if Ada discourages me from doing it for myself, it would be nice if the Ada compiler would do it for me. Bill Newman wnewman@netcom.com