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,df854b5838c3e14 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Gripe about Ada, rep specs that won't. Date: 1996/03/22 Message-ID: #1/1 X-Deja-AN: 143782822 references: <00001a73+00002504@msn.com> <4isol4$dm7@ra.nrl.navy.mil> <4iv0g6$6cs@news4.digex.net> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-03-22T00:00:00+00:00 List-Id: In article <4iv0g6$6cs@news4.digex.net>, Doug Rogers wrote: >>Why do you believe otherwise? > >Because I've never had C_E raised when doing so. I guess it's time to send a bug report to your compiler vendor. I can understand the temptation to learn the language by just noticing what some compiler does -- it's easier than learning a zillion rules. But then once in a while you'll get the wrong idea from some compiler bug. Admittedly, all the fancy checking Ada requires isn't much use if your compiler doesn't do it right. >>I imagine that if you and enough others paid ACT for a support contract, >>they would implement it. I agree, it would be nice to have this >>support. Not quite nice enough to require in the Standard, though. > >That's why I think Ada, despite its many advantages over other languages, >won't prosper. That's why embedded designers cringe. We spend many >man-months just overcoming these "little" obstacles. It's only taxpayer >money, though. ;) Well, maybe, but which other languages demand packed-arrays of 9-bit-components? It doesn't make sense to switch from Ada to language X because Ada doesn't have this feature, if language X doesn't have it either. E.g. in C, I think you'd end up doing all kinds of by-hand stuff too, which is exactly what you're complaining about in Ada. There are many cases where Ada rep clauses don't work. (E.g., try to specify the layout of the segmentation tables of the 80386.) That doesn't necessarily imply that rep clauses are useless, and it *certainly* doesn't imply that Ada is inferior to a language that doesn't have any kind of rep clauses at all. > -- And this won't work (under the 3 implementations I've tried): > pragma Pack (Item_Lists); What do you mean by "this won't work"? It should compile under all compilers, but most compilers won't pack it as tightly as you want them to. By the way, if you're using Ada 95, you should be saying: for Item_List'Component_Size use 13; Which means you want exactly 13 bits, and give me an error message if you can't do that. Pragma Pack just means pack it "reasonably" tightly, but I don't care too much if there are a few wasted bits here and there. But you're right -- either way, many Ada compilers will not support tightly-packed arrays of 13-bit components. To me, it seems reasonable that this should be a market-driven thing -- if enough people want that feature, vendors will do it. > -- Something like this is at the beginning of the file: > type Headers is record > List_Count : Nat16; > First : Nat16; > Last : Nat16; > end record; > >And, now, to make matters worse, I'd like to read this record, mixed >in with Headers, from a binary file. Perhaps the Streams stuff would help. It is intended for reading and writing heterogeneous streams of data like this. >Sorry for the confusion. I didn't mean that .File_IO was standard in >any way. I'm using it only as a means to compile my code completely, >and even run it, under Linux without having to spend all day ftp-ing >back and forth to an Alpha OpenVMS station. > >You're correct. The body depends on it. But (correct me again if I'm >wrong again), there are generic procedures in the package, so the body >of any package that uses my Seq_Mix_IO package will "use" the body >of Seq_Mix_IO. I get: > >gcc -c -gnat83 ephemerae.adb >sequential_mixed_io.adb:20:06: (Ada 83) child units not allowed >..for each instance of the generic Put/Get This sounds like unfriendly behavior on the part of gnat. There is no semantic dependence on the body of a generic, but gnat introduces a code-generation dependence on the generic body. It seems to me that the code generation dependence should not cause such a complaint. Of course, -gnat83 is not a standard feature. It won't kill you if you simply omit it. >Perhaps I should change the subject and list my (reduced) source. OK. - Bob