Re: integer'image

Re: integer'image

[Arthur Evans]

Michael Feldman (mfeldman@seas.gwu.edu) asks about the leading space in
INTEGER'IMAGE.

An Ada 9X Revision Request asking to eliminate this space was rejected
by the Requirements Team.  I don't speak for the Team.  However, I've
always assumed that the space was for symmetry with negative numbers.
That is, +N and -N always have a 'image of the same width.

Yes, getting rid of that space is a bother.  Better is to instantiate
Integer_IO.

Art Evans
Software Engineering Institute
Carnegie Mellon University

Re: integer'image

[Michael Feldman]

In article <10140@as0c.sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) writes:

>An Ada 9X Revision Request asking to eliminate this space was rejected
>by the Requirements Team.  I don't speak for the Team.  However, I've
>always assumed that the space was for symmetry with negative numbers.
>That is, +N and -N always have a 'image of the same width.
This is utter nonsense. Why not give me a width parameter such as I have in
Integer_IO already? I've always envisioned the 'image and 'value attributes
as, inter alia, a baseline of operations with which to WRITE I/O routines,
equivalent to the atoi and itoa calls in the C library. I realize you don't
speak for the team, so this flame is not aimed at you, but flame it is.

If I can't get a flush-left string out of 'image, it's virtually useless.
And if 'image and 'value aren't symmetric, why not? 'value reads past
whitespace; why should 'image give me gratuitous whitespace? Look at C.
Let me do my own padding, guys. The nonuniformity in attributes is
utterly maddening in Ada. I'll give more examples sometime.
>
>Yes, getting rid of that space is a bother.  Better is to instantiate
>Integer_IO.
Yeah, right. So what good is 'image? Any comments from Team members?

Mike Feldman

Re: integer'image

[Hoysch]

	I think a big thing is being made out of something that is not very
hard to do.  For example INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST) will
do it or a very simple routine if this is too hard on the eyes.  That 
space, as has been pointed out, is often nice to have to offset the '-'
of negative numbers.

			Dan "Hoysch" Heuschele	

Re: integer'image

[Michael Feldman]

In article <1991Jan20.025451.29808@ucselx.sdsu.edu> hoysch@ucselx.sdsu.edu (      Hoysch) writes:
>
>	I think a big thing is being made out of something that is not very
>hard to do.  For example INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST) will
>do it or a very simple routine if this is too hard on the eyes.  That 
>space, as has been pointed out, is often nice to have to offset the '-'
>of negative numbers.
>
Well, that'll work if I is positive. Otherwise it'll delete the -. So in
any case a test is needed to ascertain the sign. I'd prefer for 'image to
give me what's there, not add extra stuff that I have to delete.

One purpose for the 'image and 'value attributes, it seems to me, is to aid
in _writing_ I/O packages in lieu of (or on top of) Text_IO. The extra
blank just adds an extra bit of aggravation. I'd be happier with it if it
incorporated a general "pad" parameter, but it doesn't.

Recall that the thing that started this thread was developing a terminal-
control package that could easily ship ASCII sequences to a terminal to do
cursor movement, etc. There is no doubt that what you wrote is correct, for
positive values. I was complaining about the arbitrary lack of uniformity
in attributes, and this was the latest. I claim it's much easier to _add_
a blank to get the symmetry between positive and negative numbers than to
_delete_ the blank as you did. Ada9x is looking into the whole problem of
"edit-directed output", which will, if they really do it well, solve a lot
of these problems in a much more general way. Meanwhile, I don't like the
asymmetry between integer PUT and integer'image; in the former I can control
the width precisely because they thought to give me a parameter; in the latter
I cannot, and they decided to stick me with a gratuitous blank. I don't
think gratuitous padding is very user-friendly. The early subset compilers,
by the way, didn't add the blank - it got stuck in there somewhere between
the '80 and '83 versions of the standard, and I think they blew it.

Mike

Re: integer'image

[Jerry Callen]

In article <1991Jan20.025451.29808@ucselx.sdsu.edu> hoysch@ucselx.sdsu.edu (      Hoysch) writes:
>
>	I think a big thing is being made out of something that is not very
>hard to do.  For example INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST) will
>do it or a very simple routine if this is too hard on the eyes.

It will also chop off the minus sign if the value happens to be negative.
Furthermore, the generated code will almost certainly gag a maggot. 

Another suggestion has been instantiating integer_io and using put to a
a string; fine, but now you get to carry around the baggage of the entire
integer_io package (which may or may not be significant, depending upon
the compiler, linker, etc.).

I hate the $#@ leading space. I can usually just live with it. Nearly all
of my use of integer'IMAGE is in debugging code anyway...

-- Jerry Callen
   jcallen@encore.com

Re: integer'image

[Steven V. Case]

In article <13874@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes:
> In article <1991Jan20.025451.29808@ucselx.sdsu.edu> hoysch@ucselx.sdsu.edu (      Hoysch) writes:
> >
> >	I think a big thing is being made out of something that is not very
> >hard to do.  For example INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST) will
> >do it or a very simple routine if this is too hard on the eyes.
> 
> It will also chop off the minus sign if the value happens to be negative.
> Furthermore, the generated code will almost certainly gag a maggot. 

I have encountered this situation frequently enough that I work around it
by calling a subprogram to strip leading spaces.  I suspect that most of you
have some sort of string manipulation package that you have either 
developed or purchased.  I made sure that mine has support for removing 
leading and trailing spaces (in addition to other operations).  Then when I
want to get rid of the trailing space, I don't have to embed statements
like INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST), but can use a statement
such as REMOVE_LEADING_SPACES(FROM => INTEGER'IMAGE(I)).  This is probably
more readable, therefore it won't 'gag a maggot'.  I suspect this is the
general idea that Mr. Hoysch was suggesting when he said 'or a very simple
routine if this is too hard on the eyes.'

-- 
  ____  ____        Steve Case - HQG526           email: case@shamash.cdc.com
 / ___||___ \       Control Data Corporation      AT&T : (612) 853-3345
| |___  ___| |      3101 East 80th Street                 
 \____||____/       Bloomington, MN 55425

Re: integer'image

[Jerry Callen]

In article <29979@shamash.cdc.com> case@shamash.cdc.com (Steven V. Case) writes:
>[various quoted material deleted; essentially, a routine to stripped
> leading spaces can be used to trim the leading blank from the
> result of integer'IMAGE on positive integers. Then...]
>
>... I don't have to embed statements
>like INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST), but can use a statement
>such as REMOVE_LEADING_SPACES(FROM => INTEGER'IMAGE(I)).  This is probably
>more readable, therefore it won't 'gag a maggot'.  I suspect this is the
>general idea that Mr. Hoysch was suggesting when he said 'or a very simple
>routine if this is too hard on the eyes.'

I wasn't complaining about Ada code readability; sure you can hide the
ugliness of INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST) behind a procedure
call. I meant that the _code out of the compiler_ will be hideous; two
calls to integer'IMAGE, one to 'LAST, then a slicing operation. Yuch.
It's this sort of thing that makes C programmers look at Ada and throw
up their hands in despair.

[Don asbestos suit...]

I hate to admit it, but I'd really love an Ada equivalent of printf that
takes some nice formatting string and some variables to be printed and
then does the right thing. Occasionally (NOT very often...) strong typing
is a real pain in the buns.

-- Jerry Callen
   jcallen@encore.com

P.S. No, I'm not a C bigot; in fact, most C code is hideous enough to, well,
	 to gag a maggot. :-)

Re: integer'image

[Michael Feldman]

In article <29979@shamash.cdc.com> case@shamash.cdc.com (Steven V. Case) writes:
>I have encountered this situation frequently enough that I work around it
>by calling a subprogram to strip leading spaces.  I suspect that most of you
>have some sort of string manipulation package that you have either 
>developed or purchased.  I made sure that mine has support for removing 
>leading and trailing spaces (in addition to other operations).  Then when I
>want to get rid of the trailing space, I don't have to embed statements
>like INTEGER'IMAGE(I)(2..INTEGER'IMAGE(I)'LAST), but can use a statement
>such as REMOVE_LEADING_SPACES(FROM => INTEGER'IMAGE(I)).  This is probably
>more readable, therefore it won't 'gag a maggot'.  I suspect this is the
>general idea that Mr. Hoysch was suggesting when he said 'or a very simple
>routine if this is too hard on the eyes.'

Humbug! I hope the Ada9x team is reading this thread, to see the sort of
totally unnecessary grief is caused by what IMHO is a foolish nonuniformity
that's got to be nearly trivial to fix.

Since 'image will need to call some runtime routine to convert integer to
string, I suggest that 'image carry a second parameter, just like the
Put routines do, to control the width. So as not to disable existing programs,
default it to whatever is currently used. A Width parameter is really just the
right way, it seems to me, since then a value of 1 (or 0) says "give me exactly
the right number of characters" and a greater value suggests padding if
necessary.

Even better, give us a third parameter to control whether padding is on the 
left or on the right. Make Text_IO conform, too.

Attributes are one example of a _really neat_ thing in Ada that works 
intuitively about 90% of the time, and the 10% nonuniformity makes the
good stuff a bear to learn and causes annoyances like the above to work
around the nonuniformities.

I know, I know. I missed my shot to submit this as a revision request. I
assume someone else did, though. I'll check in my archive of RRs.

Mike Feldman

Re: integer'image

[Richard Pattis]

And add a parameter that allows padding to be a ' ' or '0' or any other
aribtrary character. For printing times, I want 12:05:07.

I think what this series of posts finally has lead to the conclusion
that everyone wants slightly different variants of the  INTEGER => STRING
conversion function.  All can be written easily, given INTEGER'IMAGE; yes,
some might be written a bit more easily if the ' ' wasn't added at the
front of non-negative numbers (but I don't claim to have any arguments
for or against).

This "problem" disappears one abstraction level up.  I can't think of
the last time I used INTEGER'IMAGE in my code (I mostly use an overloaded
& to catenate strings and numeric values, or when special formatting is
required, my own formatting routines).

I don't care what INTEGER'IMAGE does; it might be useful to have a nice
package of INTEGER => STRING functions, including conversions to roman
numerals and english: "XXVII" and "TWENTY SEVEN".

Let's get back to convincing Ada compiler developers that they can all
get rich by selling cheaply priced student compilers (and then make even
more money by selling these students special packages that perform such
conversions).

Rich Pattis

Re: integer'image

[Michael Feldman]

In article <14613@june.cs.washington.edu> pattis@cs.washington.edu (Richard Pattis) writes:
>
>Let's get back to convincing Ada compiler developers that they can all
>get rich by selling cheaply priced student compilers (and then make even
>more money by selling these students special packages that perform such
>conversions).

You're right, Rich. I've been operating on a couple of levels:

1. convince the Ada community to find nice, lucrative ways of expanding the
   Ada market, especially by hooking students and teachers on Ada, which we
   all know will have good long-term effects, as was the case with nearly
   every other language.

2. make sure that the Ada9x folks do the right thing, especially when it
   comes to little, "stupid," nonuniformities in the language that make it
   hard to learn and teach - of which the attribute system is the best
   example. I believe these little oversights can be _easily_ rectified
   given the will to do so, with little compilation or runtime penalty.
   Ada9x will be much more salable to engineers and - especially - to
   information systems folks - if more attention is paid to stuff like
   this. There are lots of little places where Ada gives with one hand
   and takes with the other, and there don't seem to be good justifications,
   just human frailty in the design. These can be fixed, given the will.

OK, enough.

Mike

Re: integer'image

[(George C. Harrison) Norfolk State University]

In article <2563@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
> In answering the question about cursor control, George Harrison and I used
> 2 different techniques to get the row and column values sent to the 
> terminal. I assumed an Integer_IO instantiation; he (probably rightly) did
> not. But all this makes me wonder why on earth Integer'Image should
> decide to prepend a blank to the numeric string. To delete this blank,
> just to get a left-adjusted numeric string, requires overkill code of
> one kind or another, as George's solution makes abdundantly clear.
> 

That's exactly right.  Do-While Jones in his _Ada in Action_ complains about
the same thing.  He then develops a package that even does essentially
Float'Image, etc.  I highly recommend the book for good reading with his [very]
dry sense of humor.  

I would like to hear if anyone feels (like me) that this book is somewhat of a
real treasure.  -- or otherwise.

George....

--------------------------------------------------------------------------
-- George C. Harrison -------------- || -- Overworked, Underpaid, --------
---|| Professor of Computer Science  || -- Unappreciated, but enjoying ---
---|| Norfolk State University, ---- || -- it all. -----------------------
---|| 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
---|| INTERNET:  g_harrison@vger.nsu.edu ---------------------------------
-- ||                 Pray for Peace and a Quick End 

Re: integer'image

[Jean Pierre Rosen]

Answer to your concern is simple: 'IMAGE is not intended for output.
As you point out, PUT is very convenient, EVEN for converting integers
to strings, thanks to the nice PUT to string.
Using 'IMAGE has other drawbacks: if you have a bounded line length,
PUT(INTEGER'IMAGE(X)) will split the number in two accross line boundary,
making it impossible to read later on, while PUT(X) will issue a
new-line correctly.
What is the advantage of using 'IMAGE? it "saves" one instantiation.
I don't see any advantage in "saving" that kind of instantiations. It
is just a bad trick that people use to often.

To summerize: if you want to drive a screw with a hammer, don't complain
the hammer's head is too large: use the right tool.

Re: integer'image

[Jim West (Stealth Contractor)]

In article <2563@sparko.gwu.edu>,
mfeldman@seas.gwu.edu (Michael Feldman) writes...

>In answering the question about cursor control, George Harrison and I used
>2 different techniques to get the row and column values sent to the 
>terminal. I assumed an Integer_IO instantiation; he (probably rightly) did
>not. But all this makes me wonder why on earth Integer'Image should
>decide to prepend a blank to the numeric string. To delete this blank,
>just to get a left-adjusted numeric string, requires overkill code of
>one kind or another, as George's solution makes abdundantly clear.
> 
>The Put operations for integers, enumerations, etc., allow you to control
>the field width exactly; you can right-adjust or you can display the literal
>flush-left. Why should the attribute not do the same? I HATE these stupid
>little counterintuitive surprises in Ada, much as I like the language in
>general. Drives students absolutely up the wall.
> 
>The Ada9x Requirements do not give any specifics in the "little things
>to clean up" category, but I surely hope the Mapping/Revision team will
>give some attention to making the whole attribute system more uniform and
>intuitive. I can give examples if anyone would like. 
>Any response from anyone on the team?
> 

  The blank is for the sign field.  Positive numbers are displayed without
the '+' sign whereas negative numbers are displayed with the '-' sign.

  If you were printing numbers that are both positive and negative then
formatting becomes easier with respect to the sign field.

  The following program and output demonstrates this.


with
	text_io,
	integer_text_io; -- preinstanciation of text_io.integer_io(integer)

procedure INT_TEST is

  x : integer := 3;
  y : integer := -5;

begin --INT_TEST

  text_io.put_line ("Here is the test...");
  text_io.put_line ("->" & integer'image(x) & "<-");
  text_io.put_line ("->" & integer'image(y) & "<-");

end INT_TEST;


Here is the test...
-> 3<-
->-5<-

  I don't disagree with you when it comes to just positive numbers and you
wish to display them without this leading blank.

----------------------------------------------------------------------
 Jim West                      |  The Schainker Converse
 west@widgit.enet.dec.com      |  to Hoare's Law :
                               |
 These are my opinions.        |   Inside every small problem
 Digital has no idea           |     is a larger problem struggling
 what I'm  saying.             |       to get out.
----------------------------------------------------------------------

Re: integer'image

[Michael Feldman]

In article <2390@shodha.enet.dec.com> west@widgit.enet.dec.com (Jim West (Stealth Contractor)) writes:
>
>  The blank is for the sign field.  Positive numbers are displayed without
>the '+' sign whereas negative numbers are displayed with the '-' sign.
>
>  If you were printing numbers that are both positive and negative then
>formatting becomes easier with respect to the sign field.
>
I know I told Rich Pattis I'd stop posting this thread to the net, but
I can't let this go by without comment. I know the idea is to get the symmetry 
with negative numbers. However, it's MUCH easier to prepend the blank if I 
want it than to strip it off if I don't. Specifically, the string form is
nice if you're writing terminal drivers (ANSI control, etc.), which only
want to see digits, no spaces. And I'd rather not waste a whole Integer_IO
instance just on that, so 'image is the nice way to go. Indeed, I thought
that was _just_ was integer'image was intended for!

I claim that

  IF X > 0 THEN
    Text_IO.Put(' ' & Integer'Image(X);
  ELSE
    Text_IO.Put(Integer'Image(X));
  END IF;

is far easier and cleaner than any of the kludges I've seen to strip the
blank. If one wants to avoid burying too many string concatenations
(storage allocation problems, it is alleged), then

  IF X > 0 THEN
    Text_IO.Put(' ');
  END IF;
  Text_IO.Put(Integer'Image(X));

fills the bill and is cleaner still. Compare that with all the junk that's
come over the net about how to throw the blank away!

I promise to finally shut up on this issue; if Ada9x hasn't gotten the message
by now, they never will.

Mike

Re: integer'image

[(George C. Harrison) Norfolk State University]

In article <2638@sparko.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
> In article <2390@shodha.enet.dec.com> west@widgit.enet.dec.com (Jim West (Stealth Contractor)) writes:
>>
>>  The blank is for the sign field.  Positive numbers are displayed without
>>the '+' sign whereas negative numbers are displayed with the '-' sign.
>>
Ya... we know that!

etc.
> instance just on that, so 'image is the nice way to go. Indeed, I thought
> that was _just_ was integer'image was intended for!

The problem really is the formatting of enumerated elements, integers, and
[ideally] floats in the middle of string expressions.

I am tired of writing

PUT("The temperature at the");
MYINTEGER_IO.PUT(N,5);
PUT(" hour is");
MYFLOAT_IO.PUT(TEMPERATURE,7,2);
PUT(" ");
MYTEMPERATURE_TYPE_IO.PUT(FAHRENHEIT);
NEW_LINE;

etc.

> if Ada9x hasn't gotten the message by now, they never will.
> 
> Mike

Ada9x-folks have to admit that just because there is a "work-around" doesn't 
mean that there are parts of this great programming language that introduce 
some unnecessary complications to do some very common things.  

-- George C. Harrison -------------- || -- My opinions and observations --
---|| Professor of Computer Science  || -- Only. -------------------------
---|| Norfolk State University, ---- || ----------- Pray for Peace -------
---|| 2401 Corprew Avenue, Norfolk, Virginia 23504 -----------------------
---|| INTERNET:  g_harrison@vger.nsu.edu ---------------------------------

Do we really want to turn off the potential Ada community or do we want them to 
enjoy the language and most of us do?  

Re: integer'image

[stephen edwards]

In article <557.27a476f2@vger.nsu.edu> g_harrison@vger.nsu.edu ((George C. Harrison) Norfolk State University) writes:
[ ... stuff about INTEGER'IMAGE deleted ... ]
>
>The problem really is the formatting of enumerated elements, integers, and
>[ideally] floats in the middle of string expressions.
>
>I am tired of writing
>
>PUT("The temperature at the");
>MYINTEGER_IO.PUT(N,5);
>PUT(" hour is");
>MYFLOAT_IO.PUT(TEMPERATURE,7,2);
>PUT(" ");
>MYTEMPERATURE_TYPE_IO.PUT(FAHRENHEIT);
>NEW_LINE;
>

Well, believe it or not, there are very trivial ways to do this easily.
Imagine being able to write the following magical expression:

    Put_Line("The temperature at the " & N & " hour is " &
    	     TEMPERATURE & " " & FAHRENHEIT);

Well, you can do this easily in Ada, albeit with the addition of a few
function definitions over and above those provided in Text_IO.  Of course,
you can wrap those in packages (generic ones, even) to use them over and
over--so you'll never have to write horrible, complicated output expressions
again! :-) :-) :-)

Of course, those who hate overloading or _use_ clauses, especially if they
are used together, will jump all over you.  However, it seems the code
is much more readable in the above example (not to mention easier to write,
and easier to maintain).  There _are_ times when these capabilities can
be very useful.

Also notice that none of these facilities require any changes to the
current Text_IO spec or implementation.  All can be layered right on
top of the existing package in a completely portable manner.

Note: actual definitions for the various instances of "&" in the above
example are left as an exercise for the reader.  For extra credit, think
about how one would extend such definitions to support the extra formatting
a fully general system might support (e.g., MyInteger_IO.Put(n,5); ...
MyFloat_IO.Put(temperature, 7, 2); ... etc., in the current Text_IO).



			-- Steve

Stephen Edwards					U.S. mail: 372 Jones Tower
e-mail    : edwards@cis.ohio-state.edu	           	   101 Curl Drive
home phone: (614)-293-0842			 	   Columbus, OH  43210

integer'image

[NANCY HEHIR]

When I run the following code

integer_string:string(1..2);
.
.
.
for x in 1..20 loop

    integer_string:=integer'image(x);
end loop;

everything is fine until x=10. This raises a constraint error which I
interpret to be a problem with mismatched string lenghts. If I increase
integer_string lenght a constraint error is raised on the first iteration.
have tried declaring integer_string as unbounded but integer'image returns a
standard string.

I'm sure that it is a standard application to convert integers to their
string images but I can't figure what I'm missing here.

Re: integer'image

[Ted Dennison]

In article <29IK4.5459$sB3.3596@news.indigo.ie>,
  "NANCY HEHIR" <nanceh.ennis@tinet.ie> wrote:
> for x in 1..20 loop
>     integer_string:=integer'image(x);
> end loop;
>
> everything is fine until x=10. This raises a constraint error which I
> interpret to be a problem with mismatched string lenghts. If I

> I'm sure that it is a standard application to convert integers to
> their string images but I can't figure what I'm missing here.

The problem isn't your integer-string conversion idiom, its your string
assignment idiom. You can't expect to be able to assign a varying-length
string into a fixed length string. It'll only work if the lengths of the
two strings just happen to be equal.

There are several ways to save your string image. One is to initialize a
constant (or variable) with the string itself, eg:

   for x in 1..20 loop
      declare
         Integer_String : constant String := Integer'image(x);
      begin
         ...
      end;
   end loop;

Another way would be to declare a string big enough to hold the largest
value you'll get, and keep track of its length:

   for x in 1..20 loop
      Integer_String_Length := String'length(Integer'image(x));
      Integer_String(1..Integer_String_Length) := Integer'image(x);
   end loop;


Another would be to use either Ada.Strings.Unbounded.Unbounded_String or
Ada.Strings.Bounded.Bounded_String.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: integer'image

[Marin D. Condic]

Ted Dennison wrote:
> There are several ways to save your string image. One is to initialize a
> constant (or variable) with the string itself, eg:
> 
One solution you did not mention, but which is my usual fix for
assignment of strings is using the standard package Ada.Strings.Fixed.
The answer would be some version of:

Ada.Strings.Fixed.Move (
    Source => Integer'Image (X),
    Target => Some_String) ;

The cat can be skinned more than one way - which you use ends up a
matter of personal preference.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: integer'image

[Ted Dennison]

In article <38FC81C4.40BEC60B@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> One solution you did not mention, but which is my usual fix for
> assignment of strings is using the standard package Ada.Strings.Fixed.
> The answer would be some version of:
>
> Ada.Strings.Fixed.Move (
>     Source => Integer'Image (X),
>     Target => Some_String) ;

...which saves one from doing the 'Image twice. Damn, why didn't I think
of that? :-)

Thanks for the tip Marin.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: integer'image

[Marin D. Condic]

Ted Dennison wrote:
> 
> ...which saves one from doing the 'Image twice. Damn, why didn't I think
> of that? :-)
> 
> Thanks for the tip Marin.
> 
Oh hell! What do you say we co-write a paper called "How many ways can
you get an integer into a string in Ada?" :-)

Of course the *precise* behavior desired may make other techniques more
useful. Start fooling with Ada.Strings.Fixed and you have to do
justifications and trimming and stuff like that. Maybe we should look at
things like Ada.Text_IO.Editing as yet another option for getting
numbers into a string.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: integer'image

[tmoran]

> integer_string:string(1..2);
>     integer_string:=integer'image(x);
> everything is fine until x=10. This raises a constraint error which I
> interpret to be a problem with mismatched string lenghts. If I increase
> integer_string lenght a constraint error is raised on the first iteration.
>
> I'm sure that it is a standard application to convert integers to their
> string images but I can't figure what I'm missing here.
  Integer'image(1) is " 1", a two character string.
  Integer'image(10) is " 10", a three character string.
  Integer'image(100) is " 100", a four character string.
so declaing the string to be 2 characters long limits you to
integer'image of -9 .. 9.  The usual idiom is to do
    declare
      integer_string : string :=integer'image(x);
    begin
      ...
    end;
which will make integer_string just exactly the right length, not
too short and not too long.
  If you need integer_string to be available more globally, try
    integer_string : string(1 .. 4) := (others=> ' '); -- max " 999"
    ...
    declare
      this_integer_string : constant string := integer'image(x);
    begin
      integer_string
        := (this_integer_string'length+1 .. integer_string'length => ' ')
           & this_integer_string;
    end;
Alternatively, just use Ada.Text_IO.Integer_IO.Put

Re: integer'image

[MaggieJohn]

You are getting the exception because there is always a space at the beginning
of an integer'image for a '-' sign.    

Try this one:

procedure make_a_string( thing : string  ) is
    len : natural := thing'len;
     this_string : string(1..len );
begin
      -- do whatever
end;

for x in 1..20 loop
     make_a_string( integer'image(x));
end loop;