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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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!news3.google.com!feeder.news-service.com!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!usenet-fr.net!nospam.fr.eu.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: for S'Image use Func?? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Tue, 11 May 2010 23:46:09 +0200 Message-ID: NNTP-Posting-Date: 11 May 2010 23:46:07 CEST NNTP-Posting-Host: eda8789e.newsspool3.arcor-online.net X-Trace: DXC=PW0LCkTRo]keoCI^f\Y]EaMcF=Q^Z^V3h4Fo<]lROoRa8kF On Tue, 11 May 2010 13:18:39 -0700 (PDT), Maciej Sobczak wrote: > On 11 Maj, 16:24, "Dmitry A. Kazakov" > wrote: > >>> OK, really - what's exactly being inefficient in buffered input? >> >> You said it, it is buffering. > > OK, next step: what's exactly being inefficient in buffering in > buffered input? Machine instructions to execute. >>> What I want is a stream interface to the blobs that my filesystem is >>> storing for me, so that I can build higher-level constructs on top of >>> it. >> >> But if my file system already has get-line-as-an-array-of-code-points. Why >> should I go deeply down to the representation layer, to a stream of octets? > > Then you shouldn't. The point is that *my* filesystem does not have it > (it supports only blobs), so I have a valid use-case for stream of > octets. Why an Ada program handling texts need to be aware of your system? Ada.Text_IO provides an OS-independent abstraction of a text. It is a poor abstraction of a stream, it is even a poorer abstraction of space travel. So what? >>>> The bottom line is, Ada does it right (tm). >> >>> If it did it right (tm), I would not have to reinvent >>> My_Better.Text_IO. >> >> You should not. The question was about formatting, I/O is OK. > > Unfortunately, in Ada the formatting and I/O are entangled in Text_IO. No. See A.10.8(18) and F.3.3. The problem of Text_IO is columns. It was an important feature back in late 70's, but it is totally useless today. > They are "separate" in stream I/O (there is no formatting at all > there) and this is what makes stream I/O a valid basis for a custom > solution, like My_Better.Text_IO. That's exactly my point. I am not sure what do you mean here. 1. Formatting is unrelated to either line-oriented (in earlier times one called it record-oriented) or character-stream oriented I/O. 2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a system deploying native record-oriented files. And it would be just silly to emulate a stream on top of records, encode it (to escape delimiters) and then decode back to implement Get_Line! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de