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/23 Message-ID: #1/1 X-Deja-AN: 227784330 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> <3332CA3D.379F@bix.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-03-23T00:00:00+00:00 List-Id: Tom Moran says <> Well it's just possible that other people than Tom Moran have manbaged to misread what i read :-) so here is a further explanation. Of course you can use Ada to read and write a file that is logically organized as a sequential file of records, and that is exactly what Sequential_IO does. HOWEVER, the level of abstraction in C is quite different from that in Ada. In C, you know how the IO operations you write are reflected at the fundamental level of the sequential butes of a file (of course this low level understanding breaks down badly when you have more sophisticated file systems like that on the IBM mainframes or VMS, but C folks generally don't like such systems anyway ("if I can't read it with C, it must be broke") so that doesn't matter to most C programmers. The Sequential_IO, Text_IO and Direct_IO packages of Ada are at a significantly higher semantic level. You have NO guarantees, none at all, of how the logical structures they implement map down to the file level. You do have a guarantee that the same code will operate in the same abstract manner regardlless of the structure of the underlying file system, and, unlike the C programmer who sits scratching their head wondering how C stream IO maps into BSAM or ISAM file structures, the Ada programmer knows that their program will run fine, no matter what the underlying file system looks like. This has good points and bad points. The good point is this independence from the underlying file structure, the bad point is this independence from the underlying file structure! If the problem is that you want to read existing data encoded in a certain way (in the case under discussion a stream of bytes represented in a single stream file), then there is no correct Ada solution using these high level packages. Yes, you may be able to get something working by depending on non-guaranteed implementation behavior of your current compiler, but you are then writing implementation dependent code. As to how portable this code really is, who knows? Certainly the Ada reference manual gives no hint, but sometimes, as many C programmers know, you can write non-standard code that is in fact quite portable. Maybe this code is in this category, maybe it is not, who knows. I know of at least one counterexample where it would not work. Note that Stream_IO in Ada 95 is not "just another IO package", it is COMPLETELY different in style, in that, like the C streams package, it is very low level, and the mapping to the external file is defined. Stream_IO has the advantage that you really know what the mapping is, and can base portable code on this knowlegde. Stream_IO has the disadvantage that it has this low level mapping, and, for examle, I have no guess as to what Stream_IO would do on top of a BDAM file on a 360 mainframe! As for the "if I had known that Ada could not do X, I would have switched to C", either this is entirely non-serious, or if serious, then it seems odd to me. If you would switch to C on the basis of such a trivial excuse, why bother to need an excuse at all, why not just use C in the first place?