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.2 required=5.0 tests=BAYES_00,FROM_WORDY,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8a019ea882aac73c,start
X-Google-Attributes: gid103376,public
From: "Rick Flower" <Rick.Flower@trw.com>
Subject: GNAT's internal format for Discriminant Records?
Date: 1998/06/19
Message-ID: <6meah3$3b$1@cronkite.sp.trw.com>#1/1
X-Deja-AN: 364269146
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Organization: TRW, Inc.
Newsgroups: comp.lang.ada
Date: 1998-06-19T00:00:00+00:00
List-Id: <comp.lang.ada>


We're trying to do some fixed format record layouts and are
looking into using discriminants.. These record formats will be
used to send data to hardware boxes, so the overhead of
what Ada might add when using some of the slick OO features
of the language are being checked into.  Now, we've already
found that GNAT (3.10p under Solaris 2.6) adds the size of the
discriminant to the overall record size (i.e. if the discriminant is
4 bits, then 4 bits are added to the overall record size).  We
tried the same under GHS Adamulti (1.8.8D) and found that it
did NOT add that overhead.  Now, for a few reasons, it would
appear that if there are multiple platforms/compilers involved
perhaps the use of discriminants should be avoided -- am I
correct in this theory?

My reasons are listed below :

    o Portability amongst different compilers/targets
    o Fixed format record layouts that MUST not have any other
       "information", OR it must be stripped off due to these
       records being sent to hardware boxes.

We've also looked at Tagged-Types and found that GNAT
(and AdaMulti for that matter) puts a 32-bit word at the front
of a record for a tagged type and that it can be removed using some simple
address arithmetic.

Any ideas/comments on this subject would be appreciated!

Thanks!

-- Rick