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,cec65b0a3ccd802d X-Google-Attributes: gid103376,public From: "Samuel T. Harris" Subject: Re: Big-endian vs little-endian Date: 1999/02/08 Message-ID: <36BF4CB6.78CEF4CC@hso.link.com>#1/1 X-Deja-AN: 442121560 Content-Transfer-Encoding: 7bit References: <36B155D2.2E8573BB@wvu.edu> <7982p9$nll$3@plug.news.pipex.net> <36B89411.7A6CFA14@lmco.com> <36BD02DB.737849EE@hso.link.com> <79n1h0$4r1$1@nnrp1.dejanews.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Raytheon Training Inc. Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-02-08T00:00:00+00:00 List-Id: dennison@telepath.com wrote: > > In article <36BD02DB.737849EE@hso.link.com>, > "Samuel T. Harris" wrote: > > > also a security concern). Since then, I have always advocated > > producing width, image, and value functions for all important > > data types. In fact, I have generics which produce these functions > > for arrays (trivial) and records (almost trivial) so the overhead > > for developing these functions is insignificant. An they do come > > in handy when a little text_io based debugging instrumentation > > is needed. A simple put_line(image(whatever)); is always available. > > Cool idea! But what method do you use to make generation of records "almost > trivial"? And how do you handle pointers? > Glad you asked. Given the requirements that all images look like Ada aggregates, supporting format options to specify the optional "decorations" such as qualification and positional vs named notation (which I'll justify later on in this message), then you have the following needs for the generics. A generic for producing width, image, and value functions for arrays needs to know the type name as a string for qualification, the width, image, and value functions for the index type (usually readily available from the appropriate attributes), the width, image, and value functions for the component type (possible made available from a previous instantiation of one of these generics). I believe we all can see the trivial nature of the width and image functions. The value function is not so trivial, having to support an optional qualification and having to deal with named and positional notation. But its not too difficult once a little effort if put into it. Of course, an initial version of these generics can be limited to support positional notation only since this greatly simplifies the value function. A generic for producing width, image, and value functions for records is a little more trouble some. The array generic can directly use the index to get the component. The record generic cannot. So, you have to provide extra "helper" functions in the form of field-level width, image, and value functions. The record generic needs the type name as a string for qualification, an enumerated type for all the discriminants and record fields, the width, image, and value functions for this field-nameing type, and a width and image function which takes a record object and field_name and produces the appropriate result (similar to the component functions of the array generic). It is the value function which different. It has to be a procedure taking an in out record object and a field_name with the objective of filling the appropriate field with the given string. Each of the helper subprograms uses a simple case statement to call the appropriate width, image, value for the field identified. Variant records are no problem since the generic functions run through all the field names. It is up to the field-level helper subprogram to either perform an action or do nothing for fields not in the variant in use. As far as pointers are concerned, they are outputed as an allocation by the component (for arrays) or field-level (for records) subprogram. One may envision a parallel to the image function called debug which outputs the pointer itself in some appropriate format so the reader can track the actual pointers themselves. This is useful not only for debugging, but also useful when the array of pointers reuses the same pointer in several slots. The usage of allocator notation in the image does not reflect that property. OTOH, output the pointer itself with its dereference does not satisfy keeping the image compliant with Ada aggregate notation, so I usually use a separate subprogram for this or provide options to image to control the outputed format. Keeping image compliant with Ada aggregate notation is important when you consider code which have large aggregates intializing complex data structures. With a conforming image/value function pair in place, you can copy the aggregate text to a file and use the enclosing package elaboration to do text_io on the file to initialize the data structure with the image of the file contents. While this will slow down elaboration, this does allow you change the data structure without recompiling and relinking the program. I find this very powerful during development. Once the initial data is tested and locked down, you can paste it back into the declaration of the object and comment out the text_io code in the package elaboration. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!"