comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin D. Condic" <mcondic-nospam@acm.com>
Subject: Re: Representation Clauses And Freezing
Date: 2000/07/21
Date: 2000-07-21T19:28:55+00:00	[thread overview]
Message-ID: <3978A46C.19700E10@acm.com> (raw)
In-Reply-To: un1jb8ld4.fsf@gsfc.nasa.gov

Stephen Leake wrote:
> The fields you explicitly located are in the same places. I'm not
> clear why you can't live with this size and alignment for the record.
> 
Size does matter. :-) In one sense, it ought to be sufficient for me to
say "Because I just may feel like it one day!" A rep clause should give
me what I ask for (assuming it is logically possibly to do so) or it is
useless. You might as well not have it if it is going to constantly try
to out-guess you or insist that it knows what's best for you. Give me
what I ask for or tell me that you don't support rep clauses because not
giving me what I ask for is, in my mind, not supporting rep clauses.

If I'm trying to make something line up with physical hardware, then I
may very well need to control the size and having the compiler tack
extra space on the end is not going to help. It also impacts math
involving 'Size. Alignment might also be an issue if I have to
physically locate some structure at specific hardware addresses. Memory
mapped I/O devices may require all sorts of specifics that the compiler
isn't smart enough to know about - so it ought to trust me to know whats
best.

As for the space and position occupied by the tag - I think it is a
weakness of Ada that there are no attributes for at least discovering
where they live and how big they are. Given that in all probability, the
tag is going to be some contiguous chunk of bits at the start of the
record (anybody ever seen an implementation that was not?) all I really
need to know is the size so I can make my rep clauses relative to that
size. (Ada could probably have specified that it *must* appear at the
start of the record and that the first usable bit would be offset from
the front of the record by Rectype'Tag'Size or some such construct.) In
any event, I'm macho enough to figure out for the implementation what it
is and take my chances on lack of portability by defining whatever
constants I need and doing my own adjustments to get around the tag.


> Perhaps you see it as "easier" in C because C doesn't have tagged
> types, so none of the issues you are raising here occur.
> 
> You can always convert a tagged record into an equivalent variant
> record. Perhaps you cannot afford the run-time overhead to do this, so
> you are trying to map the tagged record directly onto the byte stream.
> I agree that is a neat way to do things.
> 
You might want to go to my web page (http://www.mcondic.com/) and look
on the Ada page (http://www.mcondic.com/Ada_Programming.html) for the
paper I put there describing some of the issues involved in message
passing systems and where there are issues with how Ada does things.

I don't want to try to describe how all of the message passing issues
can be handled in C (or Jovial - which did a very nice job of giving me
what I asked for :-) but basically you'd be doing it by (in effect)
creating your own "tagged records" and doing your own dispatching. You
still kind of have to do this even with Ada tagged records on the input
side, because you have no clue what you have until you start decoding
the raw data. Because C barely has any typing enforcement in comparison
to Ada, you can dummy this up fairly readily - if dangerously.

Variant records don't cut it and there's generally too many restrictions
on them to make them do what you need to do here in an easy way. (You
may be able to get there, but it just gets *hard* to constantly be
trying to overcome the strong typing all the time. Remember, you're
fundamentally dealing with raw data onto which you want to sometimes
impose order - at least at the low level of the communication interface.
The strong typing can go back to being an asset once you get the data a
sufficient distance from the hose.) See my paper and you may get a
handle on what it is I want and why I want it.

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
======================================================================




  reply	other threads:[~2000-07-21  0:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-17  0:00 Representation Clauses And Freezing Marin D. Condic
2000-07-17  0:00 ` Stephen Leake
2000-07-20  0:00   ` Marin D. Condic
2000-07-20  0:00     ` Stephen Leake
2000-07-21  0:00       ` Marin D. Condic
2000-07-21  0:00         ` Simon Wright
2000-07-22  0:00           ` Marin D. Condic
2000-07-22  0:00             ` tmoran
2000-07-22  0:00               ` Marin D. Condic
2000-07-24  0:00               ` Ted Dennison
2000-07-21  0:00         ` Stephen Leake
2000-07-21  0:00           ` Marin D. Condic [this message]
2000-07-21  0:00     ` tmoran
2000-07-18  0:00 ` Tucker Taft
2000-07-18  0:00 ` Nicolas Brunot
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox