Prev: Question about default discriminants and mutable objects.
Next: Why is not Stream_Access defined Ada.Streams ?
From: Warren on 10 May 2010 14:50
Dmitry A. Kazakov expounded in
> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:
>> Dmitry A. Kazakov expounded in
>>> 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
>>> 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
./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:
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? 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
> 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".
From: Yannick Duchêne (Hibou57) on 10 May 2010 15:09
Le Mon, 10 May 2010 18:18:47 +0200, Warren <ve3wwg(a)gmail.com> a écrit:
> I wrote the initial APQ
> binding, which I trust is now in good hands.
What's APQ please ?
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just
From: Niklas Holsti on 10 May 2010 15:20
> Dmitry A. Kazakov expounded in
>> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote:
>>> 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.
Yes you do...
> What you end up having to do is to
> test for line number changes instead-- yuk.
.... if you read character by character, use the function
Text_IO.End_Of_Line to detect the end of an input line. This works the
same way in all systems, whatever line termination character (sequence),
if any, is used. Follow with Skip_Line to go to the start of the next line.
To return to the subject: I too often use 'Image for normal output, not
just for debugging. And I find the extra blank annoying. But it is a
very small annoyance, considering what else life offers :-)
niklas holsti tidorum fi
. @ .
From: Warren on 10 May 2010 15:57
Georg Bauhaus expounded in
> On 10.05.10 18:18, Warren wrote:
>> Georg Bauhaus expounded in news:4be3d4fb$0$7651$9b4e6d93
>>> [1. mislead assumptions].
>>> If, as Bob has said, programmers discover 'Image before
>>> they discover Text_IO.*_IO and Text_IO.Editing, then there
>>> is something wrong, indeed---with Ada's appearance before
>> I know all about the instantiated Text_IO stuff. The
>> prevailing thing here is that I use S'Image for debugging
>> a lot (saves me from also having to track down instantiated
>> packages when I want to remove it). Then there's the
>> lazy part of me, that wanted to capitalize on what was
>> already there.
> (I have "with Debugging;" in many context clauses.)
>> Shoot me for those reasons. I've forgotten some Ada,
>> but I'm not a newb either.
> APQ is not forgotten ... The point is that, like J.-P. Rosen
> said, and like you said, 'Image is for debugging.
Yep. Up until this point, I've used To_String() functions,
but I do like the suggested "Image" for the function name.
Thanks for the lively discussion,
From: Warren on 10 May 2010 16:01
=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in
> Le Mon, 10 May 2010 18:18:47 +0200, Warren <ve3wwg(a)gmail.com> a �crit:
>> I wrote the initial APQ
>> binding, which I trust is now in good hands.
> What's APQ please ?
Originally was here:
But now is hosted here now (AFAIK):
and gratiously maintained by Marcelo Cora�a de Freitas.