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: Doug Rogers Subject: Re: Gripe about Ada, rep specs that won't. Date: 1996/03/21 Message-ID: <4isol4$dm7@ra.nrl.navy.mil>#1/1 X-Deja-AN: 143658288 references: <00001a73+00002504@msn.com> <3146E324.5C1E@lfwc.lockheed.com> <4i98gg$8n1@solutions.solon.com> <4ia41k$e04@solutions.solon.com> <4ik5ip$cl6@watnews1.watson.ibm.com> <4iq71v$cvr@news4.digex.net> content-type: text/plain; charset=us-ascii organization: Naval Research Laboratory x-url: news:dewar.827374356@schonberg mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.1N (X11; I; Linux 1.3.69 i486) Date: 1996-03-21T00:00:00+00:00 List-Id: dewar@cs.nyu.edu (Robert Dewar) wrote: > >"The problem is even worse for records (and variant records, >which are another gripe of mine -- no true "union" -- don't >get me started!). >" >I don't know what you mean by a "true" union, but I have this nasty feeling >that what you meanis someting like the C union. Ada says no thankyou >to such obvious disastrous holes in the type system. If you are >programming at this level, you need some definite indication that you >are breaking the type system. Unchecked conversion may seem hideous, >and that's the point. Breaking the type system *is* hideous. Well, that's quite a nice bit of high-road preaching from behind your dais up there :-), but Ada does NOT protect you from those holes. Regardless of the value of the discriminant, you can still access ANY of the fields in a variant record. In fact, if I could rely on something like Constraint_Error in those cases, I'd probably begrudgingly accept the variant records of Ada. As it stands now, though, it just gets in my way without providing any protection: I cannot set the discriminant, and yet I can access another discriminant's fields. >As for obeying every possible rep clause, it would be a mistake to >require compilers to do things that do not fit the hardware well, because >the effort to implement these would be very large, and the benefit to >most users very small, since most Ada programmers do not want to write >code that generates hidden inefficiencies. >So far, we saw no customer who needed tightly packed 9-bit fields. If >we saw customers who needed this feature, it would appear in GNAT :-) I'm using GNAT for prototyping. Here's my vote for packed types of all sizes. Of course there's overhead. You have to keep track of each index's bit position, not just its address. Tell me which has greater cost, though, overhead in the compiler development or in the development of each project that has to interface with embedded hardware? My current project doesn't even interface with low-level hardware, but it receives a datastream from a satellite instrument which has multiple formats (and yes, one of them has an array of 9-bit values!). And, as a bonus, Ada provides no language standard means for accessing variable-length records in its file-i/o packages! (I'm stuck with Ada83, since I'm on a DEC, and DEC Ada provides Sequential/Direct_Mixed_IO packages for such things). It's funny to hear "market-driven" as a rationale for whether or not a feature is to be implemented in Ada! :) By the way, since you're a GNAT developer (I assume from your message), perhaps you can help with one minor problem of mine. As I mentioned above, DEC Ada provides a Sequential_Mixed_IO package, which contains generic procedures to get/put items of any type. Because I don't have direct access to the target machine, and I hate the DEC editors, I do all my development under Linux. I've written my own version of Sequential_Mixed_IO for GNAT, but since it uses System.File_IO and various other Ada95-specific packages, I can't use -gnat83. Is there a way that I can make my package appear as if it were a standard Ada83 package, even though it must do direct File_IO operations? Doug Rogers PS - As I've said in the few bug reports I've sent in, you guys have done a wonderful job implementing Ada95. I really enjoyed coding object-oriented Ada over two years ago, before the standard was even making rounds for final approval. But Ada is Ada... :-)