Re: calenday (was Re: IBM Acquires Rational Ada

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

Randy Brukardt <randy@rrsoftware.com> wrote in message
news:v04c0ul05vht40@corp.supernews.com...
>
>
> a) is not a problem in practice. We did this in Claw, and all compilers
> put the tag at offset 0. (A few can be told to put it elsewhere, but
> that wasn't generally available a few years ago when we did that.) The
> size is a problem in that it is implementation-defined.
> Ada.Tags.Tag'Size is the correct value, but it isn't static, so you
> can't use it in representation clauses. We ended up declaring a constant
> TAG_SIZE that we use in the rep. clauses (and compare to
> Ada.Tags/Tag'Size as a validity check). However, it is 4 (bytes) in all
> of the compilers that we tried, so it really wasn't necessary.
>
I'd suspect that declaring in the standard that all tags shall start at
offset 0 and extend for 32 bits would not cause anyone any rework. I doubt
it would come up often that the offset needed to be anything other than
zero - I can't think of why I'd want it to or why I couldn't make things
work somehow if it were always zero. Having a predefined constant for size
and a mandated (dare I use that word?) starting point at the beginning of
the record ought to be good enough.


> b) is clearly compiler specific. I'd suggest trying to convince your
> compiler vendor to improve their compiler. Janus/Ada doesn't require any
> alignment for the extension part. And I don't recall having problems
> with this in Claw, although perhaps we were lucky.
>
Well, someone must have thought it was more important to longword-align
things than to give the programmer what he asked for. :-) The important part
is that if you're going to have a rep-clause, it needs to give the
programmer control over the representation - even if it introduces
inefficiencies.


> The biggest non-portability is in the ability (or lack thereof) to put
> extension components into "holes" in the parent. This is useful, but can
> be really hard to implement (it causes problems with the predefined "="
> operation, and I believe that there are other problems that I don't
> remember at the moment).
>
That starts sounding a bit extreme. The overwhelming bulk of the time, I'd
be trying to use rep-clauses because things are packed tightly together -
not overlapping things. Most typically for tagged records, you'd have a
class called "Message" that included message header info then followed by a
variety of message formats - very naturally expressed in OO Design. But if
you can't control representation, you can't make it work with what happens
on the wire. Short of the base class ending in the middle of a byte (never
seen that) and wanting the derived class to pick up in the middle of that
byte, I can't think of a case where I'd want derived class parts put into
holes in the base class. Maybe it happens, but I think you could probably
put on my tombstone "He never packed derived class data into holes in the
base class..." :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================