Re: for S'Image use Func??

[Warren <ve3wwg@gmail.com>]

Dmitry A. Kazakov expounded in
news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net: 

> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:
> 
>> Dmitry A. Kazakov expounded in
>> news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg@40tude.net: 
>> 
>>> On Mon, 10 May 2010 15:48:19 +0000 (UTC), Warren wrote:
>>> 
>>>> Another thing that bugs me is that the Ada.Text_IO
>>>> will not return a LF character (like getchar() in C).
>>> 
>>> Why should it? It is a text I/O not a stream I/O.
>> 
>> But if I recall correctly, I also cannot get an
>> empty string as input. An empty string is still
>> valid input.
> 
> Hmm, try this:

Ok, good- that at least works. 

But you have no way to know when you've read 
a empty line in a lexer routine that is reading 
character by character. 

What you end up having to do is to
test for line number changes instead-- yuk.
Then if you need that null line, you have to
back fill it with extra code. More guk.

But your point about "stream i/o" is a good
one. Perhaps it is just my bad for using the
wrong tool.

>>> C's I/O is a disaster, 
>> 
>> You have only listed an opinion when you don't 
>> list specifics.
> 
> Did you used it? 

For at least a few decades. ;-)

> Character input returns integer

In C, that is a feature. The macro EOF is
defined as (int)(-1), which is something that
is never read into a char (unless perhaps
you use a silly signed char type).

> , file is a number,

Ever heard of stdin (0), stdout (1) or stderr (2)?
Of course you have.  From the shell, you can also
do:

  ./myprog 7<my_input 8>aux_output

and from within a C program, you would intuitively
do I/O with units 7 and 8 (in addition to the "standard"
0, 1 and 2 units). Not many people think past the
"standard units", but they are usable when required.

They're not Ada type safe obviously (as int), but
is otherwise "in C terms" just fine.

> sometimes a pointer, 

If you do buffered I/O, you use an "object". Ada 
supports objects too - but you know that already.

> do you use  fseek or lseek? 

That is easy-- if you look at the parameters. Oh and
there is another giveaway -- most of those FILE * 
routines start with the letter "f".  Not a perfect
convention, but effective all the same.

> Is errno thread safe

It wasn't when threads first came on the scene, but 
is definitely so now. That is precisely why you must:

  #include <errno.h>

instead of the old fashioned:

  extern int errno;

So there was a technology change. That doesn't render the
C I/O system as a "disaster". If you want to say that you
"don't like it", then I can accept that.  That's different ;-)

As a design foundation for all those Unix, Linux and *BSD 
platforms, I don't think you can call it a disaster. In fact 
even MS o/s's (and IBM's O/S2) have implimented their own 
versions of this posix paradyme.

>> C of course did
>> the same thing, except that they made formatting a string
>> easier.
> 
> Easier? It is untyped! 

No, no, no "said the fish as he lit to the Cat in the Hat".

You exaggerate. It is not strongly typed like Ada, but
by George, there are "types" in C.  You can think of C
differentiating on the basis of "base" types. 

I once programmed in "B" a very long time ago. Everything 
was a "word" or a float type (2 types). That just is about 
as close to "untyped" as you can get AFAIK.

> There is no thing worse than that. We
> constantly fight with catching:
> 
>    printf ("%s", X);
> 
> X is an object of the type having implicit conversion to const * for
> output purpose.

Modern versions of gcc does catch most of these abuses.
But I agree that lacks the strengths that Ada does have.

But you've taken my point to the rediculous instead of 
discussing my point about formatting data. I just cited
one common and concrete formatting instance that gets 
used in C frequently, that you cannot do in Ada "out 
of the box".

>>> I wonder why people paying so much attention to
>>> admittedly broken and misplaced formatting of Ada.Text_IO in the
>>> times of GUIs. It won't work anyway. It is not a text anymore.
>> 
>> Do you enter a picture when login to your favourite GUI
>> system? A wave file for your password?  We still depend 
>> a lot on Text. Look at any database- it's not all about
>> blobs.
> 
> No, it is, for instance, about columned output of fixed point numbers
> in proportional font aligned along the decimal point...

And what goes into that font drawing call? Text. Yes, you
can mess with proportional fonts if you like, but it isn't 
always that way.  In fact, there are many instances where
proportional fonts are a curse. I frequently look for ways
to undo this "modern feature".

Warren