From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 15 Apr 92 17:56:41 GMT From: elroy.jpl.nasa.gov!grian!puffin!pete@uunet.uu.net (Pete Carah) Subject: Re: integer'image versus integer_io Message-ID: <1992Apr15.175641.5785@puffin.uucp> List-Id: In article <1992Apr13.113149.20126@hellgate.utah.edu> Kevin Simonson writes: > If I want to output an integer to standard output, or to a file, I can >do it either by instantiating the generic package "integer_io", or by using >the "integer'image" attribute. Therefore the following code gives me iden- >tical results: > The only difference I get from my compiler is that with the "'image" >version there's an extra space in front of the integer for a sign value. > My question is, if you want to output integers mixed with text, and if >you don't mind about that first position for the sign, is there really any >reason to use an "integer_io" instantiation over just using >"integer'image"? Well, with Meridian (and probably most other ada systems), if you use 'image for ANY type too long you will run out of memory. The return value of 'image is a dynamic string, which is NEVER DEALLOCATED. I'm not sure if unchecked_deallocation would be safe on this string, since it may be part of a larger data structure that was allocated. That would be implementation- dependent. I *have* seen this attack us in a production program whose writer thought 'image was a fine way of doing I/O, and it worked for ALL of his test cases, then failed (in front of the customer) when the input data set was a little longer than expected... We had great fun fixing it, 'image was buried all over the place. > It seems like the "'image" version would be more effective, too, since >in the other version I'd have to use three I/O calls, versus the one I/O >call for the concatentated string. What do you mean by effective? "efficient?" Maybe not; the malloc calls add up too. For sufficiently small programs/output sets, or on a 32-bit virtual memory system with no process-size limit, yes it will work, and MAY be more efficient. On any program whose output size depends on its input size, and which will be used by those other than the authors, avoid it like the plague. Lest you think this is unique, see the problems the C shell had when it was first ported to non-virtual memory systems; it ran out of memory doing aliases with fairly small numbers of them. The fact that it was written on/for a vax hid the memory leaks from the authors. (or they may have deliberately ignored them thinking the shell would never be used on a "small" machine). Assumptions like this tend to come back and bite you IN ANY LANGUAGE. ADA actually hides this stuff from the user better than C, and thus encourages memory waste. > If anybody knows any reason why concatenating "integer'image" might >cause me any grief, please let me know. See above. BTW - text_io CAN also suffer from the same problem; a decent implementation won't. In my ("embedded") system (runs on a PC but acts embedded), we don't even use text_io since it is rather a pig (and I thought C stdio was big...), and I couldn't use the OS output calls anyhow since it messes up the graphics. I just wrote specific conversion routines for the number types I needed. Yes, I know, text_io does provide string conversion calls. That still brings in the whole 130+ K package. -- Pete (pete@puffin.uucp)