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" Subject: Re: Text_IO for other standard types Date: 1998/01/12 Message-ID: <34BA9133.7B4B@online.no>#1/1 X-Deja-AN: 315337913 Content-Transfer-Encoding: 7bit References: <98010912585349@psavax.pwfl.com> <34B7AF17.311F@online.no> <34B88301.4BC4@online.no> Content-Type: text/plain; charset=us-ascii Organization: Jensen programvareutvikling Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-01-12T00:00:00+00:00 List-Id: Robert Dewar wrote: > 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. This sounds eminently sensible. When I program in C I try to remember to first flush stdout then print the error message and finally flush stderr before exiting on error conditions. However as also noted below, this is of little value for those distributing code unless the other vendors does the same. > > The GNAT manual also outlines how to control buffering if you don't > like the default. I still think it should be an official way of manhandling buffering. In many applications there is a marked improvement in performance when using largish buffers. > > 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. I'm focusing on buffering because it would be the easiest one to fix. And since I have been around for a while I think I have noticed the effect on languages which did not support buffering. Apparantly you have fixed it in your implementation, but have the other vendors done likewise? If not we end up programming in GNAT Ada, Aonix Ada, Intermetrics Ada, etc. Greetings, -- // Tarjei T. Jensen // tarjei@online.no || voice +47 51 62 85 58 // Support you local rescue centre: GET LOST!