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,7c0437014cb20f71 X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: System.Address_to_Access_Conversions Date: 1998/07/27 Message-ID: <98072709565446@psavax.pwfl.com> X-Deja-AN: 375485025 Sender: Ada programming language Comments: To: matthew_heaney@acm.org X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" Newsgroups: comp.lang.ada X-VMS-Cc: SMTP%"matthew_heaney@acm.org",CONDIC Date: 1998-07-27T00:00:00+00:00 List-Id: Matthew Heaney writes: > >"Marin David Condic, 561.796.8997, M/S 731-96" writes: > >> This made tagged records a major nuisance to >> me when trying to utilize them in a communications situation where >> I wanted to beam the bits down a wire. > >If something is a "major nuisance" to do, then you should interpret that >to mean that you shouldn't be doing it. Actually there is a good reason to try to do this. When writing software to do communication of messages down a wire, you really want to "have it both ways" You want strongly typed data so that you can properly interpret the messages, yet you also want the ability to treat them as raw bytes when doing the actual transmit/receive. Without going into it in too much depth, what I was trying to do was something that is easily done in assembly or other weakly typed languages (without any protection) but has been traditionally hard to do in Ada without introducing major inefficiencies. Tagged records provide a mechanism with which to do it reasonably well, but you have to go through some gyrations with streams to strip out the tags. (And most folks wouldn't care, but when you're trying to do this on a schedule, the extra layers of data motion become a "major nuisance".) > >Do not try to send a tagged type directly across an external interface. >You must first convert the object to an external format, preferably >using the streams facility and/or the DSA. Never tried to. Unless you can control *all* of the data you are sending, you shouldn't be trying to send it because you don't know what will be at the other end. The "stream" business provides an answer, (maybe) but not as good a one as I would like. It would have been better if I had the ability to control the placement and content of the tag, which would mean I could strip it out or otherwise get the raw bits I wanted with Unchecked_Conversion. Or barring that, at least be able to use the tag as a message ID or, with known size and placement, have it "reserved" in the message catalog so the other side knows to ignore it. It would take pages to try to explain exactly what I am doing with tagged records in this particular situation. They can be used and they do provide an answer for internal architectural problems. You just have to beg and plead with the compiler or find a way to deal with double buffering timing delays because of the lack of control over representation issues. > >> There is a way to use streams to get rid of the tag information if >> you need to do it, but if you are in some way interested in >> utilizing tagged records to overlay physical hardware, etc., you >> will find there are no good answers. > >No good answers, becuase the question itself is all wrong. Which, as I recall, was the original poster's question about tagged records. I'm not sure why he wanted to overlay tagged records onto hardware, but (given that I've been there myself in embedded applications) I will reserve judgement on it being a good or bad idea. Often you have some slick software architecture plan and then you get down to having to connect to physical hardware that was designed by guys who are mostly familiar with assembly language programming - maybe Fortran - but have no concept of what you'd like to do in software. So you have to look for a way to connect up your slick software design with the physical characteristics of the hardware. (Consider that you'd like to apply the latest ideas of Object Oriented Programming to an embedded application - "Tagged records, let me introduce you to Hardware...") Maybe that's where he was at. I'd agree that it is not a desirable place to be, because you have so little control over the representation of tagged records. But that doesn't necessarily mean that a tagged record (or discriminated record or plain vanilla record) might not be the best logical representation of the problem. > >> If you come across information that suggests a solution to >> controlling representation of tagged record types that sounds >> standard and portable, I'd be interested in hearing about it. > >Please don't fight the language, as there are "standard and portable" >ways to get the job done. That the representation of a tagged type >isn't under programmer control is a feature, not a flaw. > Not being completely dim, I seldom tilt at windmills anymore and don't generally want to "fight the language". Still, I've needed control over tagged records and to date, the only mechanism that works completely is to know exactly what a given compiler produces and rely on those assumptions. Dangerous, volatile, and not standard or portable, but it has been known to work. It may be your only choice unless the project can afford to buy some compiler writers and eat the time needed to get the changes made. "Standard and portable" can be vastly overrated. In the embedded world, you quite often are looking at a situation where you are going to freeze the hardware and the compiler and it will remain thus for many years to come. In the event of "new" hardware or a similar system, you are almost always back at ground zero anyway, so you can forget "portability" without modification. (Yes, you do get to reuse software, but either a) it is at an abstract enough level where you don't care about representation anymore or b) it is at a sufficiently low level that you are going to have to change everything for hardware differences anyway, so the representation will have to be revisited no matter what you do.) Besides, a change in hardware typically means such a huge investment in other things that to develop the software again completely from the ground up is so far down in the weeds that nobody cares. I'd have to respectfully disagree about the lack of control of the representation of tagged types being a "feature" instead of a "flaw". Here's where I come from on that topic: Either a) I have no interest in how the bits are ordered, or b) I do. If the situation is A, then the compiler is free to do what it likes and I need no representation clause for a tagged record. If the answer is B, then I can look to the representation clause - which legally applies to tagged records - to get the control I want. If, however, the introduction of the representation clause only allows me to control the ordering of *some* of the bits, then I might just as well not have it at all, because that original condition is bistable: I either need control or I don't. So the fact that the representation clause won't let me deal with the tag, or the alignment as I extend a tagged type or in any other respect where the compiler is going to refuse a legitimate specification of representation, then there might just as well have been a rule in the language that said "representation clauses cannot be applied to tagged types". A prime example of this is when you have to build software which must respond to messages defined long ago and may be sent from anywhere. The bit ordering is what it is and you are not free to change it. So either you can control the representation of your data structures and take advantage of modern programming concepts (enumerations, discriminated/tagged records, abstract data types, etc.) or you can't control the representation and have to program at the lowest level of bit-twiddling to deal with reality. Naturally, I'd prefer to use the more advanced concepts and leave the shifting & masking of bits to the compiler. I've had reasons in the systems I design to use representation clauses for just about every kind of data type imaginable. If for no other reason than to guarantee the assumptions on which a system is founded, just in case someone tries to port the code or a compiler switch is made midstream. I appreciate it when the compiler notices that I've specified some representation is logically impossible. It would be nice if the compiler would warn you of potential inefficiencies in the representation you choose. It would be even nicer if the compiler were to spit out a pictorial memory layout of the representation you specified. But in all cases where I've specified what should be a legal specification and had it rejected by the compiler, I've cursed the developers for second-guessing me. The representation clause is supposed to be a "Trust me, I know what I'm doing" sort of thing similar to Unchecked_Conversion. Sorry for going off on a harangue - it's one of my favorite things to get frustrated about with compilers! MDC Marin David Condic, Senior Computer Engineer Voice: 561.796.8997 Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600 Fax: 561.796.4669 West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM ============================================================================= "The race is not always to the swift, nor the battle to the strong - but that's the way to bet." -- Damon Runyon =============================================================================