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: 101deb,495b037244521cf3 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,22b2c05a8088bbb2 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Leading zeros with Int_IO.Put()? Or another package? Date: 1996/11/28 Message-ID: <57j1eh$kfp$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 201171278 references: <327FB8A3.745B@itg-sepg.logicon.com> <55ubsh$lh0$1@goanna.cs.rmit.edu.au> <56bi13$3pa$1@goanna.cs.rmit.edu.au> <328A0DDD.94B@lmtas.lmco.com> <56rgou$r4k$1@goanna.cs.rmit.edu.au> <56tjrh$4ak$1@goanna.cs.rmit.edu.au> <56trsm$f5a$1@goanna.cs.rmit.edu.au> <56u4vf$r65$1@goanna.cs.rmit.edu.au> <57381t$at8$1@goanna.cs.rmit.edu.au> <573mrl$3v2$1@goanna.cs.rmit.edu.au> <578rdj$3lj@mulga.cs.mu.OZ.AU> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.pl1 nntp-posting-user: ok Date: 1996-11-28T00:00:00+00:00 List-Id: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: >ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: [the point of putting picture declarations with data is so that they can be revised if the data scale/precision/&c is revised.] >Still, that's not going to look good if your 131-column printouts now >become 133 columns wide, forcing either wrap or truncation when you try >to print them on a standard 132-column printer. I haven't seen a "standard 132-column printer" in nearly 20 years. I went to an accountant this morning to have him do our tax return. Form filled in using a flashy Win3.1.1-for-workgroups spreadsheet of some kind (with a bug; apparently something has been carried over every year since 1990!) and will be printed on A4 paper. A couple of years ago I got something from a lawyer that used the ISO 646 minus sign (code point 2/13) instead of the decimal point (code point 2/14); I tried to explain the problem but never did get it across. Standards? Feh! >>A layout is used to write *DATA*. It's not "where is it going" >>that determines what picture should be used, but "what am I writing". Of course wrap-around matters. This is why the behaviour of the Put procedures in Ada.Text_IO and its children is not *always* appropriate. If a Fortran format isn't big enough for the data, you get stars instead. If a C format isn't big enough for the data, the field expands until it _is_ big enough, and presto chango! your record overflows. Ada "Put" procedures are just like C in this respect. The Ada designers were not blind to this, which is why Ada.Text_IO.Set_Line_Length exists. This would more adequately address the problem of wrapping if only there were some way to ask Text_IO to raise an exception if the record to be generated overflows, instead of quietly wrapping. At least the wrapping is done treating the current output item as a single unit, so that line breaks only occur _between_ units. Could an implementation co-opt the FORM parameter in the Open or Create call for this purpose? >"What am I writing" is important, but sometimes "where it is going" >matters too. Nobody is denying this. However, this turns out to be an even _stronger_ argument in favour of moving the pictures out of the PUTs and giving them names, because then the program can check itself. Suppose I want to write a record containing - specified String variables and constants - data edited using named pictures. Then I can *once* in my program, at startup, do if Line_Length(Current_Output) < S1'Length + .. + Sn'Length + Length(Pic1) + ... + Length(Picx) then raise Configuration_Error; end if; It is much easier to get this right when the pictures have names. -- Fear most of all to be in error. -- Kierkegaard, quoting Socrates. Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.