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: "Tarjei T. Jensen" <tarjei@online.no>
Subject: Re: Text_IO for other standard types
Date: 1998/01/11
Message-ID: <34B88301.4BC4@online.no>#1/1
X-Deja-AN: 314890983
Content-Transfer-Encoding: 7bit
References: <98010912585349@psavax.pwfl.com> <34B7AF17.311F@online.no>
 <dewar.884460172@merv>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Jensen programvareutvikling
Newsgroups: comp.lang.ada
Date: 1998-01-11T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert Dewar wrote:
> 
> 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).

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.

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

Which translated should mean "No, we don't do any buffering". That is a
pity, because it would be a morale boost for many newbees that their Ada
programs were as fast on I/O as anybody elses C or C++ programs without
having to do any tweaking.

I think that the spitbol pattern matching library and I/O buffering
could have been a powerful combination. Assuming of course that the
library has a sensible interface.


Greetings,

-- 
// Tarjei T. Jensen 
//    tarjei@online.no || voice +47 51 62 85 58
//   Support you local rescue centre: GET LOST!