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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,c689b55786a9f2bd X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!s29g2000yqd.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: for S'Image use Func?? Date: Wed, 12 May 2010 06:16:05 -0700 (PDT) Organization: http://groups.google.com Message-ID: <199e07cb-2e93-40fc-974d-000b83b6000f@s29g2000yqd.googlegroups.com> References: <4be417b4$0$6992$9b4e6d93@newsspool4.arcor-online.net> <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net> <87632vwikr.fsf@ludovic-brenta.org> <112n6z3554srr$.tjzjtg467xfo.dlg@40tude.net> <1fv8frriu1h4s.g9jy78q1c0io.dlg@40tude.net> <7a31eab7-1a1c-4653-bf49-ff1498e318f9@b18g2000yqb.googlegroups.com> NNTP-Posting-Host: 137.138.182.236 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1273670165 25383 127.0.0.1 (12 May 2010 13:16:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 12 May 2010 13:16:05 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s29g2000yqd.googlegroups.com; posting-host=137.138.182.236; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:11548 Date: 2010-05-12T06:16:05-07:00 List-Id: On 11 Maj, 23:46, "Dmitry A. Kazakov" wrote: > > OK, next step: what's exactly being inefficient in buffering in > > buffered input? > > Machine instructions to execute. Yes - by proper use of buffering I can *reduce* the number of machine instructions to execute and therefore make the program run faster. Note also that the number of machine instructions is only a partial problem - another is delays introduced by some of them. Sometimes it is better to execute more instructions that keep the pipeline full than to execute less of them, but with delays or blocks. > Why an Ada program handling texts need to be aware of your system? Because it is running on my system. It's a pretty good idea to have some local awareness. > Ada.Text_IO provides an OS-independent abstraction of a text. The above is not even wrong. Ada.Text_IO cannot even *name* all the files that I have on my hard drive. Even assuming that I can open some file, the whole "abstraction of a text" is severely limited. I cannot, for example, read the second paragraph of the third chapter of the book that is in the file. This "abstraction" is really a stream on steroids, nothing fancy. > > Unfortunately, in Ada the formatting and I/O are entangled in Text_IO. > > No. See A.10.8(18) and F.3.3. Wrong. They do not relate to Text_IO. Even assuming wider context, formatting without I/O is trivial, but I cannot have I/O without formatting. Text_IO gives me both. But on the other hand, I'm not sure how I/O without formatting would look like - that would have to be a plain stream. Which means that your "abstraction of a text" is little more than a bit of formatting glued on top of a stream. > The problem of Text_IO is columns. Not only. It cannot detect the end of stream without blocking, for example. > 2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a > system deploying native record-oriented files. I'm OK with that. The whole thing is so unportable already that limiting it further to only those systems that I will ever want to use is not a problem for me. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4