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!b18g2000yqb.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: for S'Image use Func??
Date: Tue, 11 May 2010 13:18:39 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: 
 <7a31eab7-1a1c-4653-bf49-ff1498e318f9@b18g2000yqb.googlegroups.com>
References: <Xns9D7085FECB88EWarrensBlatherings@188.40.43.213>
	<Xns9D70A3756AAE0WarrensBlatherings@188.40.43.213>
 <wccmxwcu6kc.fsf@shell01.TheWorld.com>
	<op.vcaxs1h4ule2fv@garhos> <wcceihou455.fsf@shell01.TheWorld.com>
	<hs0jm5$vr4$1@news.eternal-september.org>
 <wcchbmjlx6a.fsf@shell01.TheWorld.com>
	<4be417b4$0$6992$9b4e6d93@newsspool4.arcor-online.net>
 <wccpr17yeji.fsf@shell01.TheWorld.com>
	<Xns9D747817630D6WarrensBlatherings@188.40.43.245>
 <zvtps4jzmo1z$.mzhapf4p7b4a.dlg@40tude.net>
	<Xns9D7482F0549D2WarrensBlatherings@188.40.43.245>
 <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net>
	<b7b2dcd9-92d4-40f3-ab85-5c0dfdecb832@b7g2000yqk.googlegroups.com>
	<87632vwikr.fsf@ludovic-brenta.org>
 <112n6z3554srr$.tjzjtg467xfo.dlg@40tude.net>
	<eddcbcc0-d9fc-4675-909a-d4a8478733ad@d27g2000yqc.googlegroups.com>
	<1fv8frriu1h4s.g9jy78q1c0io.dlg@40tude.net>
NNTP-Posting-Host: 81.62.42.71
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: posting.google.com 1273609119 17446 127.0.0.1 (11 May 2010 20:18:39
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 11 May 2010 20:18:39 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: b18g2000yqb.googlegroups.com; posting-host=81.62.42.71;
	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:11528
Date: 2010-05-11T13:18:39-07:00
List-Id: <comp.lang.ada>

On 11 Maj, 16:24, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
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?

> > 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.

> >> 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.
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.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4