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,4b862d91ff93feff
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Text_IO for other standard types
Date: 1998/01/11
Message-ID: <dewar.884522547@merv>#1/1
X-Deja-AN: 314923556
References: <98010912585349@psavax.pwfl.com> <34B7AF17.311F@online.no>
 <dewar.884460172@merv> <34B88301.4BC4@online.no>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 884522941 19983 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-01-11T00:00:00+00:00
List-Id: <comp.lang.ada>


Tarjei said

<<Which system will not benefit from doing fewer, but larger writes or
reads when doing general I/O such as screen writes and reading and
writing to files?

As the buffering have few if any "user servicable parts" it would be
perfectly reasonable to ignore some of the buffering requests and
perhaps even raise exceptions on others.

This is the usual case of someone somewhere MIGHT not benefit, so
therefore nobody can have it. Despite the obvious advantages.
>>


You still miss the point. Buffering is not a language feature except
to the extent that you could imagine defining the language in a way
that made it impossible to buffer, but Ada clearly allows buffering
(that is why there is a flush operator).

In GNAT, our normal approach is to buffer files except in the case
where the output is to standard output *and* the output is directed
to a non-regular file (typically the terminal). Certainly users,
*especially* beginners, find it easier if terminal output is not
buffered by default.

The GNAT manual also outlines how to control buffering if you don't
like the default.

Tarjei, this really seems like a tempest in a teapot! You are foucussing
here on buffering, but I think you should be focussing on efficiency.
What would be helpful is to write a program in C and Ada that shows
up the efficiency differences you are talking about, and then analyze
them. Most likely, to the extent such efficiency differences exist, they
have little to do with buffering, but are rather the effect of a much
higher level semantics on the Ada side, e.g. line/page counting. Actually
Stream_IO is a much better semantic level match to ordinary C stream
I/O and that is part of the reason it was put into the language.