Re: for S'Image use Func??

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 11 Maj, 23:46, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > OK, next step: what's exactly being inefficient in buffering in
> > buffered input?
>
> Machine instructions to execute.

Yes - by proper use of buffering I can *reduce* the number of machine
instructions to execute and therefore make the program run faster.

Note also that the number of machine instructions is only a partial
problem - another is delays introduced by some of them. Sometimes it
is better to execute more instructions that keep the pipeline full
than to execute less of them, but with delays or blocks.

> Why an Ada program handling texts need to be aware of your system?

Because it is running on my system. It's a pretty good idea to have
some local awareness.

> Ada.Text_IO provides an OS-independent abstraction of a text.

The above is not even wrong. Ada.Text_IO cannot even *name* all the
files that I have on my hard drive.

Even assuming that I can open some file, the whole "abstraction of a
text" is severely limited. I cannot, for example, read the second
paragraph of the third chapter of the book that is in the file.
This "abstraction" is really a stream on steroids, nothing fancy.

> > Unfortunately, in Ada the formatting and I/O are entangled in Text_IO.
>
> No. See A.10.8(18) and F.3.3.

Wrong. They do not relate to Text_IO.

Even assuming wider context, formatting without I/O is trivial, but I
cannot have I/O without formatting. Text_IO gives me both.
But on the other hand, I'm not sure how I/O without formatting would
look like - that would have to be a plain stream. Which means that
your "abstraction of a text" is little more than a bit of formatting
glued on top of a stream.

> The problem of Text_IO is columns.

Not only. It cannot detect the end of stream without blocking, for
example.

> 2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a
> system deploying native record-oriented files.

I'm OK with that. The whole thing is so unportable already that
limiting it further to only those systems that I will ever want to use
is not a problem for me.

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

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