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/22 Message-ID: <3979C22C.627F3C89@acm.com> X-Deja-AN: 649499098 Content-Transfer-Encoding: 7bit References: <3973192E.E7337814@acm.com> <397707E2.CCDB7C44@acm.com> <39784AC3.C2A2B817@acm.com> Organization: Quadrus Corporation X-Sender: "Marin D. Condic" (Unverified) X-Server-Date: 22 Jul 2000 15:48:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-07-22T15:48:23+00:00 List-Id: Simon Wright wrote: > I do agree. But, you are trying to do this with tagged types, and the > tag part is not specified by the standard. > I understand this. See my other post where I whine and snivel about the standard not specifying some attribute(s) to enable you to do this. :-) At least you can get there with some system dependencies, but they'll be isolated at the lowest level and I generally consider that "fair". > If you have the same release of the same compiler on the same hardware > at both ends, why use rep clauses? (I'm assuming that the tag isn't a > pointer to a type-specific dope structure -- if it was you would be > completely wrong to try to send such data over the wire or even > inter-process). > I understand and agree that this is one possibility. However, if you're building a system that is going to be around for a while and is not for some very narrow application, you can bet money that you won't have the same compiler/version/hardware at both ends. You send a message to the outside world and you don't know what will be at the other end over time. If your device is useful, someone may want to hook some completely as yet unknown device to the same wire and want to utilize your message catalog for as yet unknown purposes. It happens all the time. Either that, or you're connecting to someone else's message catalog that is already defined & can't be changed. Hence, you want your message catalog to be very explicit and detailed because this represents your "contract" (dare I use that word here? :-) with the outside world. > If you have any difference at all, you *can not* sensibly send tags > over the wire. > I don't want to send the tag. I want to strip it out and just send the data and let the other end figure out what it wants to do with it from there. The basic idea here is that if I could build a base class that defined a message header and all of the low-level services needed to transmit/receive the messages, I could then very easily extend the base class for whatever message passing system I have to build and not worry about the low level details. Key to this is that the low-level operations are class-wide. No matter how you extend the message, the base class needs to be able to determine where the "real" data is in the record, how big it is, how to checksum it, how to interpret it as raw bytes, etc, etc. In a weakly typed language, you could do this by basically passing the address of any structure and its size in some TBD manner and the low level stuff would just send/receive it as bytes. You can get there with Ada, but you'd prefer to work with what would be the more "natural" method of tagged records. (I've seen it done in Ada with addresses, but the code begins to get ugly and doesn't seem to provide the kind of abstraction that would make it very clean.) I don't want the derived classes to have to provide similar operations - just the stuff needed for the content of the extended message. I don't want the derived class to have to provide conversions to a stream or anything like that because it shouldn't have to and it only creates extra programming work (chances for errors, etc) and inefficient message passing. (Remember, I'm "real-time" here and this is often a critical issue.) If the base class can deal with the offset of the tag and can reliably get the size of the record, then you can handle this fairly well. You just define an array of bytes and overlay it on the tagged record. You can then compute the message size and a checksum if needed, fill in whatever header information you want and blip the stuff down the wire. It's harder on the way back in, because you are going to have to recreate the tagged record from a message ID (some version of a case statement to do your own dispatching, so you'll need knowledge of the other derived types at that juncture) but there's no way around that one no matter what you do. Still, the base class can tell you what kind of message you have from the header and put the bytes into the derived class once you've determined the record type. Obviously, this is all dependent on being able to control the representation of all the messages and not having anything spurious in the record beyond the tag. If you're curious about it, I've got a paper on my web page that describes it (originally aimed at being a kind of "training" thing for the uninitiate - so its kind of basic.) http://www.mcondic.com/Ada_Programming.html (towards the bottom) There's also some code to try to illustrate where I'm trying to go. If you look it over and have suggestions, I'm all ears. 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 ======================================================================