Re: calenday (was Re: IBM Acquires Rational Ada

["Randy Brukardt" <randy@rrsoftware.com>]

Marin David Condic wrote in message ...
> 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.

As noted elsewhere, Rational has at least one customer that wants to be
able to place tags, and both Janus/Ada and Rational Apex support
non-zero tag locations. Asking us to remove functionality (with the
possibility for incompatibilities) is not likely to be looked on kindly.

And, as also noted elsewhere, there are machines out there where a
pointer (and thus a tag) is not 32-bits. How would you suggest we
implement that rule on the U2200 with its 36-bit words (and pointers)??

>> 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..." :-)

Well, it comes up when you're trying to minimize storage of the types,
and the parent has unused bits. Consider:

     type Root_Type is tagged record
         Int : Some_Int_Subtype;
         Is_Valid : Boolean;
    end record;
    for Root_Type use record
        -- We assume the tag is at 0 and is 32 bits. A real rep. clause
would use a constant instead
        -- of assuming the tag size is 4 below.
        Int at 4 range 0 .. 15;
        Is_Valid at 6 range 0 .. 0;
    end record;

The bits 1 .. 7 in byte 6 are unused, as is byte 7. Now, look at the
extension:

     type Day is (Sunday, Monday, ....);

     type Day_Type is new Root_Type with record
            The_Day : Day;
     end record;
     for Day_Type use record
            -- The_Day at 6 range 1 .. 4; -- No extra space needed. But
fills a hole.
            The_Day at 7 range 0 .. 3; -- Extra byte needed.
            -- The_Day at 8 range 0 .. 3; -- Insisting on alignment
makes it worse. Probably a 4 extra
                                                             -- bytes
when allocated.
     end record;

And you waste even more space if some of the extension components need
alignment.

If there are going to be a lot of these (as there might if these are
used in compiler expression trees, for example), the wasted space can
turn into a lot of extra memory overhead (meaning longer compile times
in this example).

         Randy Brukardt.