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/10
Message-ID: <dewar.884460172@merv>#1/1
X-Deja-AN: 314723994
References: <98010912585349@psavax.pwfl.com> <34B7AF17.311F@online.no>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 884460370 12544 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-01-10T00:00:00+00:00
List-Id: <comp.lang.ada>


Tarjei said

<<I think the first priority should be to repair the standard I/O library.
I think there is too much unsaid. E.g. Ada does not demand buffered I/O
therefor most vendors seems to think that they should not provide such a
facility. Result; even the most horrible C program outperforms almost
any Ada program. And Ada gets to be known as a sloooooow programming
language.
>>

I have no idea what buffering means semantically, other than the
language allowing buffering (clearly Ada does which is why there
is a flush operation), but you cannot somehow insist on buffering,
what on earth would be the point. A language standard is not in the
business of providing possibly faulty advice on how to implement
things efficiently (buffering can slow things down on some systems
by introducing an extra level of unneceessary copying).

As for Ada I/O being slower than C I/O, how about a very specific
example of what you are talking about. Usually when we look at exact
code, we find the situation is not at all what it sounded like from
a rough general description of this kind.