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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9c86eb13dd395066 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: CRC in Ada? Date: 1997/03/19 Message-ID: #1/1 X-Deja-AN: 226732853 References: <1997Mar2.220652@nova.wright.edu> <331bf6ce.2832564@news.logica.co.uk> <332B5EBD.3D9E@worldnet.att.net> <332C9185.61C1@worldnet.att.net> <332F5CC8.6D7C@worldnet.att.net> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-03-19T00:00:00+00:00 List-Id: Michael said <> No, you felt compelled to *misuse* an Ada 83 I/O package and write highly non-portable code that relied on the inner workings of sequential_io in your particular implementation. OK, if you lacked the knowledge to write the trivial pragma Import for the appropriate C routine (I assume this if it would have taken you half a day), then you may have been stuck, and generating this solution may have been the best you could do. But it was NOT the right solution in Ada, since it did not meet the spec of the problem except by accident. You cannot expect to do everything in Ada. Suppose I tell you to write an Ada program that plays a tune on the speaker. You have around a C callable routine called Play_Tune that does exactly what you want, but instead you write a hairy piece of Ada that uses address clauses to directly address the memory mapped IO port for the speaker, and write loops with the right frequencies to play the tune. Your solution is all Ada. Is it therefore superior? no it is perfectly horrible, and we assume no one would make such a mistake. But your approach was a (much less obvious and not nearly so horrible) example of the same mistake. The fact of the matter is that there WAS no suitable routine in the Ada 83 IO library to solve your problem, just as there is no Play_Note routine. When you have this situation, then you use pragma Interface, that is what it is for! Now in Ada 95, we have Stream_IO which is suitable for solving your problem, and comparisons of comaprable code using Stream_IO with corresponding C code are much more meaningful, but it still may be appropriate to use pragma Interface. In London a couple of years ago, I gave a talk "Sleeping with the Enemy", and the theme was that the attitude that C and C++ and ??? are horrible languages and that you must never go near them is a counter productive one for Ada programmers. On the contrary, there is lots of useful stuff there, and a competent Ada programmer knows when and how to take advantage of it. Note that of course the C or C++ programmer who has a similar view of Ada (horrible language, don't want to go near it, don't know, don't want to know) is similarly hobbling themselves. <>. Nope. That misses the point again, you are not comparing one compiler with another, but rather two completely different solutions, one using a library routine appropriate to the job, with another solution using an entirely inappropriate library routine. It would not surprise me at all if the difference you see, a factor of 30, has nothing at all to do with buffering, but rather is a natural consequence of the implementation approach for sequential_IO, which is undoubtedly written to be reasonable for correct use of the package, and which may well be slow for this clear misuse. Just to get a bit of a feel for what I mean by sequential_IO being at a different level of abstraction from the C getchar, look at the following little bit of code in GNAT's Ada.Sequential_IO.Read: -- For non-definite type or type with discriminants, read size and -- raise Program_Error if it is larger than the size of the item. if not Element_Type'Definite or else Element_Type'Has_Discriminants then FIO.Read_Buf Now, given a macro substitution approach to generics, it is likely that this code is optimized away, but in a shared generic approach, it is likely to be a real test, and it is certainly a test that would not conceivably be present in the C routine. Does this mean that sequentio_Io is less efficient than the C routine, no! It means that they are doing different kinds of things. If someone compares the peformance of log in C and sqrt in Ada and tries to draw conclusions about the efficiency of languages, libraries or compilers from such a comparison, we would immediately see it as absurd. Comparing getchar in C with sequential_IO.get in Ada is only slightly less absurd!