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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,c689b55786a9f2bd X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.68.MISMATCH!feeder.news-service.com!newsfeed.straub-nv.de!eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: for S'Image use Func?? Date: Mon, 10 May 2010 18:50:02 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <4be417b4$0$6992$9b4e6d93@newsspool4.arcor-online.net> <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net> Injection-Date: Mon, 10 May 2010 18:50:02 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="6638"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zzn7GBgj5B0lmztTQKIiT4qHWicwE/BE=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:UqIIIVZUOQk6ibyFSWM10preIhs= Xref: g2news2.google.com comp.lang.ada:11461 Date: 2010-05-10T18:50:02+00:00 List-Id: 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 7aux_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 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