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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,65f09e2d2d4dad56 X-Google-Attributes: gid103376,public From: "Marin D. Condic" Subject: Re: Representation Clauses And Freezing Date: 2000/07/21 Message-ID: <39784AC3.C2A2B817@acm.com> X-Deja-AN: 649089116 Content-Transfer-Encoding: 7bit References: <3973192E.E7337814@acm.com> <397707E2.CCDB7C44@acm.com> Organization: Quadrus Corporation X-Sender: "Marin D. Condic" (Unverified) X-Server-Date: 21 Jul 2000 13:06:29 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-07-21T13:06:29+00:00 List-Id: Stephen Leake wrote: > > Making the compiler happy isn't really the issue. If I could accept > > whatever the compiler insisted on giving me, then I wouldn't need a > > representation clause, right? > > But you can give a rep clause. It's just not the same one as you could > give if the type were public. So I don't understand what the problem is. > Are you serious? What good is a rep clause unless it is the rep clause that *I* want? If any old rep clause would do, then why bother putting one on there at all? Decoration? Try to imagine that you want to line up a data type to match a hardware register or a message coming into a system from the outside world. You have to put a rep clause on the data type so that specific bits, bytes and words fall into specific positions. Having the compiler reject your rep clause and suggest another does absolutely no good and is totally pointless. > Compilers are free to choose the implementation for tagged types. This > compiler apparently has a representation for private tagged types that > is slightly different then for public tagged types. Your rep clause > does not completely specify the full tagged type. So again, what is > the problem? > Thats just another way of saying "it is legal behavior for a compiler to reject all representation clauses" - which is another way of saying that it is totally useless. I understand that a compiler needs to be in a position to pick the representation of the tag, but I ought to be able to own the entire rest of the record - including any derivations thereof. If the compiler wants to own bits 0..31, that's fine with me, but I want to own bits 32..N and get exactly what I specify. No longword alignments I didn't ask for. No extra spare space between fields. Nothing but precisely what I specify - otherwise it does me no good. You might just as well have said "representation clauses on tagged records are illegal in Ada" because it amounts to the same thing. > > First, the rep clause you gave was rejected by the compiler, so you > need to find out why and/or fix the rep clause so it will be accepted. > Bzzzzzzzt. Wrong answer. :-) My rep clause expresses a legitimate representation of the data in legal syntax. A compiler is free to reject it and claim to be validated. Fair enough. But if it rejects it and claims to be useful - "just change your representation to my representation" then I must regretfully reject the compiler for this application. Now if there is another way of *expressing* the same representation that the compiler will like better, I'll accept that as a workaround - but that's like saying "if it won't accept it on a tagged record, then just don't use tagged records - use a regular record or an array of raw bytes or something else." Sure, you can do that, but then you lose the use of the language feature and you're back to asking what good is it to have a rep clause for a tagged record? Why not just program the whole thing in assembly language? > > You'll have to be more specific. I don't see a significant difference: > > Method 1: > > type Specific_Rep_Type is record > something : integer_32; > something_else : integer_32; > end record; > for Specific_Rep_Type use record > something at 0 range 0 .. 31; > something_else at 4 range 0 .. 31; > end record; > for Specific_Rep_Type'size use 64; > > type Object_Type is tagged record > specific_stuff : Specific_rep_Type; > end record; > Is the following statement guaranteed to be true? Object_Type'Size = Specific_Rep_Type'Size Well of course not. We've got to account for the tag so I'll accept subtraction of a constant to remove the tag. Is the following statement true in all cases (assuming the tag is a 32 bit word) (Object_Type'Size - 32) = Specific_Rep_Type'Size Now go extend that Object_Type with Another_Specific_Rep_Type and are you guaranteed that (New_Object_Type'Size - 32) = (Specific_Rep_Type'Size + Another_Specific_Rep_Type'Size) The answer, BTW, is "no". The first one *may* hold by accident, but is not guaranteed because Object_Type may extend its size to do word alignment, etc. The second one doesn't hold, again because the compiler may choose to start the additional fields at any offset from the beginning of the record. Why do I want to do this? I suppose its not going to be sufficient to say "because I just do!" :-) Try putting an overlay of a byte array on top of the record. Why? It's a really fast way of translating the record into something you can run down the wire to someone else. You get your structured data for 99% of the computing and you get your raw data for the 1% of the computing that needs to treat it as such. Isolating that in the non-visible part of the base class and making it work for all derived classes is a *really slick* way of building a message passing system. You probably also want to put a word array or longword array overlay on top of it so you can compute checksums. You also want 'Size to give you what you expect so you can compute the size of the message. Yada Yada Yada. Trust me on this - I've done a lot of message passing stuff and I've always found Ada to be a real nasty bitch (especially 83) when trying to use it for this kind of application. It is a *lot* easier to get this out of C or other languages that pretty much let you toss type safety out the window. (Don't take this as an endorsement of C - just an illustration.) And please don't offer me 'Read and 'Write. Not only is it data motion, but it degenerates to too many procedure calls and still leaves you with no good way of computing the message size or checksums as you go along. I could eat the efficiency issues on many apps, but many others can't ignore it. > You don't have a "restriction", you have a "difference in > implementation specifics between public and private tagged types". > Perfectly legitimate according to the Ada 95 standard. > And as I said before, totally useless. Just because it is "legal" doesn't make it "useful". I think the reason this problem annoys me so much is that over the years, Ada has taken a lot of heat from real time programmers because it was viewed as too restrictive. I've defended the language in most cases because I knew it well enough to know that there was usually some way of getting what you needed out of it. In the arena of message passing systems, I've always had to conceed that Ada made you do so many butt-ugly things to get what you needed done that it almost wasn't worth it. Ada95 fixed a lot of sore spots for the real time and embedded world, but I still can't build the message passing stuff in an elegant and efficient way - not unless I find a compiler that will let me get absolute control over the representation of the tagged types. Either that or give me a "union" and pointers I can translate into arrays. :-) MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity." -- Martin Luther King, Jr ======================================================================