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,2e66fe8b30e3ee2c X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Rep clause problems, was Re: S'Write and How To Count Bytes Date: 2000/10/06 Message-ID: <39DDCD18.D925057@acm.org>#1/1 X-Deja-AN: 678275633 Content-Transfer-Encoding: 7bit References: <39D9DD58.86538032@acm.org> <39DA256D.D854277B@acm.org> X-Accept-Language: en X-Server-Date: 6 Oct 2000 13:00:55 GMT Content-Type: text/plain; charset=us-ascii Organization: Quadrus Corporation Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-10-06T13:00:55+00:00 List-Id: Simon Wright wrote: > I thought you had predefined message formats, which have to be > understood by code over which you have little control. So this format > will specify field locations and (if you're lucky) endianness. What it > certainly won't contain is a space for an Ada tag. > In the case I'm working on now, I do have a predefined message catalog. Presuming that you do something with representation clauses on tagged records rather than using a stream, you have some work to do. The tag in the record, you have to get rid of in an implementation dependent manner. Fortunately, while there may be hundreds of ways of implementing tagged records, only one of them doesn't look silly: Put an integer at the front of the base record type. You have to figure out the number of bits and use that for your rep clause anyway, so its pretty easy to start your overlay by stepping over the tag. It would help if Ada provided attributes to help you out here - either by guaranteeing the size and location of the tag or by inventing something like: Rec_Type'Starting_Point_Of_All_Non_Tag_Stuff. The problem is you just can't seem to get control of the representation of tagged types even if you can get around the tag with minimal fuss. > > Seems to me you need packages to handle the wire formats and packages > to handle your tagged types; and when it comes to send a message you > might use streams in your tagged type package, but the implementation > of the 'Output etc will need to use the appropriate wire format > package. And the input wire format package will create and return some > object(s) in your tagged world. > That's sort of basically where I'm going for this case. I've got the tagged record where I can use 'Read and 'Write to get it in the format for the hose or get it back when I need it. Coming in, you have to do your own dispatching when looking at the raw bytes so that you can create the record type you need, but there's no way around that. If I don't get exactly the format I want by the default 'Read and 'Write, for the elementary types, I can replace them with something that will. > > I'm assuming that your tagged types are in your application domain, > not the comms domain? if the former, I've found that messages rarely > map at all to application classes; if the latter, the message set > rarely maps straightforwardly to any sort of inheritance tree. Not sure what you mean here. Let me see if I get close. All my messages have a predefined message header that contains things like a sync pattern, number of bytes, message identifier, yada, yada, yada. Then all the "application specific" data content follows this message header. The tree is very flat - although I suppose one day there may be some levels to it. Mostly, you need to pull the bytes from the wire, figure out which of maybe fifty or more messages is coming in, pull that message off the wire and let the application have at it. (Naturally, theres a lot of error checking, recovery, etc. that goes in all this too, but the process is basically that.) What I'd like is not necessarily some deep inheritance tree kind of thing. I just want to be able to treat messages as what they are - a class. All messages have some things in common - they all have a header, they all translate into a stream of raw bytes of some determinable length, they all transmit and receive up and down the same wire with the same hardware, etc. It would be nice to support all the sending and receiving and such from a class-wide set of operations and allow dispatching to handle the specific cases. 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/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ======================================================================