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,9c86eb13dd395066 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: CRC in Ada? Date: 1997/03/13 Message-ID: #1/1 X-Deja-AN: 225142610 Distribution: world References: <1997Mar2.220652@nova.wright.edu> <1997Mar5.131846.1@eisner> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-03-13T00:00:00+00:00 List-Id: In article <5g4k31$g54$1@A-abe.resnet.ucsb.edu> Graham Hughes writes: > Now, any stdio library can do this any way it damn well pleases, but the > *usual* way to implement the buffers is this: > > If you request a character to be read, it feeds you the next character > in the buffer. If there isn't a next character in the buffer, it reads > in BUFSIZ elements and tries again. If it can't read any elements in, > then it returns EOF. ... > Now, since BUFSIZ is 1024 bytes on my computer, this is in fact quite > efficient. The actual BUFSIZ varies from compiler to compiler and > platform to platform, much as stdio itself does. > > I don't see why this is so hard to do in Ada. It's the most used > library in C (even hello world programs call printf()). It's not. It's easy. But you might not get that from the way this thread has progressed. As Robert pointed out back at the start (and a couple of times since), use Read and Write directly on buffers of stream elements _instead_ of the attributes String'Read and String'Write. The latter require character by character processing (per RM element by element processing of arrays in streams). OK, so clearly the Read/Write for streams into buffers will be very efficient and you can then chop this at your leisure. But there are a still a few issues in all this. First, for GNAT String'Read/Write should boil down to a getc/putc or some such C read/write, so any extra overhead here (beyond what you have in C) should not be due to any buffering aspects whatsover. They will be due to call overhead on the C IO function. The claim that started this twist in the thread here, was that this overhead made the IO "very slow". I guess the problem is with "very". 3 times slower? 4 times? What? And are these examples of "very slow"? Perhaps. Regular ol' getchar, of course, can avoid this call overhead - though I suppose it may not: thread safety issues anyone? Second, while 13.13.2(9) sez that for composites (including arrays) the associated Read and Write attributes call the Read/Write attributes for each _component_, I don't see why this can't be one of those cases where "as if semantics" apply. For example, for one dimensional arrays, just read the thing as if you called Read/Write for each element. Third, since you can specify stream oriented attributes ('Read 'Write) for any type with an attribute definition clause, you can always just change the "efficiency" behavior of String'Read/Write to be just like getchar's by inlining a version which does what getchar does. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com