comp.lang.ada
 help / color / mirror / Atom feed
* integer'image versus integer_io
@ 1992-04-13 17:31 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!agate
  0 siblings, 0 replies; 2+ messages in thread
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!agate @ 1992-04-13 17:31 UTC (permalink / raw)


     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:

   package IIO is new text_io.integer_io (integer);
   II : integer;

   text_io.put ("Enter value:  ");
   IIO.get (II);
   text_io.put ("Value entered is [");
   IIO.put (II, 1);
   text_io.put_line ("].");

                         versus

   package IIO is new text_io.integer_io (integer);
   II : integer;

   text_io.put ("Enter value:  ");
   IIO.get (II);
   text_io.put_line ("Value entered is [" & integer'image (II) & "].");

     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"?

     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.

     If anybody knows any reason why concatenating "integer'image" might
cause me any grief, please let me know.  Respond by e-mail if you can; it
takes forever for these articles to get to my network.  Thanks.

                                     ---Kevin Simonson

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: integer'image versus integer_io
@ 1992-04-15 17:56 Pete Carah
  0 siblings, 0 replies; 2+ messages in thread
From: Pete Carah @ 1992-04-15 17:56 UTC (permalink / raw)


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)

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1992-04-15 17:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-04-15 17:56 integer'image versus integer_io Pete Carah
  -- strict thread matches above, loose matches on Subject: below --
1992-04-13 17:31 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!agate

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox