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,c1131ea1fcd630a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: To Initialise or not Date: 1996/05/10 Message-ID: <31933B50.687D@lmtas.lmco.com>#1/1 X-Deja-AN: 154167088 references: <318508FE.204B@sanders.lockheed.com> <3190A8D3.3D53@lmtas.lmco.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.01 (Macintosh; I; 68K) Date: 1996-05-10T00:00:00+00:00 List-Id: Robert A Duff wrote: > > Here's a real practical example, which might be more convincing than > vague notions of readability: > > I have a program that uses access types. I want to convert to using > integers, where the integers point into an array. There are several > reasons you might want to do that. E.g. if you know you only have a > small number of heap objects, you might be able to make the integer > smaller than an access value. It might make it easier to manage your > heap in some way that is not directly supported for access types. > > If you followed the convention of always explicitly initializing access > types (either to null or to whatever the right value should be), then > this conversion can be fairly mechanical -- change "Foo.all" to > "Heap(Foo)", where Heap is the array representing the heap. Change > "null" to "Null_Pointer", where Null_Pointer is a constant initialized > to an integer number representing null, and so on. I thought I was convinced by this, but on reflection... 1. Are you converting _all_ access types to encoded integers, or just a particular _use_ of an access type? If the latter, then you can't do it completely mechanically (assuming more than one access type) for all occurences of null. You still have to find the specific declarations that need to be modified. Since you have to do that anyway, you're really not gaining much by denoting them with an explicit null. Now, if you had a different name for null for each access type, this might work. Otherwise, I don't think you gain very much. 2. Assuming you really _are_ converting all access types to integers (or even if you're not, now that I think about it), you have a different problem. To retain your (presumably desired) behavior of an implicit null being used to catch errors, you also have to come up with some way to trap references to your uninitialized integers. This means you have to visit those declarations with the implicit null, and either assign them an out-of-range value (Null_Pointer, maybe?), or do something else. (You probably will also want to add the appropriate assertions in your code before you "dereference" the integers. However, even if you didn't add the code, the Null_Pointer assignment would still be useful for debugging purposes...) 3. Both of these actions (replacing the explicit null with Null_Pointer, and the implicit null with... Null_Pointer?!?) can be done mechanically (and with less human error, I suspect), without the explicit null - assuming you have a tool that does data flow analysis, or at least can track declaration/use information. In fact, the explicit null could actually reduce the effectiveness of such an analysis. I know that, particularly with older code that has been maintained by several parties, I would trust an automated analysis tool over your coding convention. So, I'm still not convinced. > > - Bob -- LMTAS - "Our Brand Means Quality"