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,7c0437014cb20f71 X-Google-Attributes: gid103376,public From: Stephen Leake Subject: Re: System.Address_to_Access_Conversions Date: 1998/07/28 Message-ID: #1/1 X-Deja-AN: 375713595 References: <98072709565446@psavax.pwfl.com> Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Newsgroups: comp.lang.ada Date: 1998-07-28T00:00:00+00:00 List-Id: "Marin David Condic, 561.796.8997, M/S 731-96" writes: > Matthew Heaney writes: > > > >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. But that is exactly what 'input and 'output give you! You control how the tag is represented in the stream, and where it is placed. Both ends of the stream agree on the stream representation, but can have different internal reps. > 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". I'll agree with that. If a tagged type is a good logical representation, you can still need several untagged types to map to the hardware, so you can apply representation clauses. > 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. Again, you need two types; one that matches the predefined structure (untagged), and one that makes it more logical (tagged). -- Stephe