for S'Image use Func??
in [ADA]
|
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 news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg(a)40tude.net: > On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote: > >> Dmitry A. Kazakov expounded in >> news:zvtps4jzmo1z$.mzhapf4p7b4a.dlg(a)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
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 not lucky
From: Niklas Holsti on 10 May 2010 15:20 Warren wrote: > Dmitry A. Kazakov expounded in > news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg(a)40tude.net: > >> 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 Ltd niklas holsti tidorum fi . @ .
From: Warren on 10 May 2010 15:57 Georg Bauhaus expounded in news:4be84851$0$6891$9b4e6d93(a)newsspool2.arcor-online.net: > On 10.05.10 18:18, Warren wrote: >> Georg Bauhaus expounded in news:4be3d4fb$0$7651$9b4e6d93 >> @newsspool1.arcor-online.net: >> >> .. >>> [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 >>> them! >> >> 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, Warren
From: Warren on 10 May 2010 16:01
=?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in news:op.vch7hze9xmjfy8(a)garhos: > 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: http://sourceforge.net/projects/apq But now is hosted here now (AFAIK): http://framework.kow.com.br/projects/show/apq and gratiously maintained by Marcelo Cora�a de Freitas. Warren |