comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Should representation clauses be complete for each bit?
Date: Fri, 22 Jul 2011 19:13:02 -0500
Date: 2011-07-22T19:13:02-05:00	[thread overview]
Message-ID: <j0d3mh$oae$1@munin.nbi.dk> (raw)
In-Reply-To: wcchb6fbs04.fsf@shell01.TheWorld.com

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcchb6fbs04.fsf@shell01.TheWorld.com...
...
> Part of my complaint is that you have to say it twice:
>
>    type Bits2 is mod 2**2;
>    pragma Assert (Bits2'Size = 2);

There is a reason that Ada has constants. ;-) And I have no idea why you are 
using an Assert here rather than specifying the Size oughtright (I always do 
that in such cases):

   Gap1_Size : constant := 2;
   type Gap1_Bits is mod 2**Gap1_Size with Size => Gap1_Size;

This gives a compile-time failure if there is something wrong with the Size, 
not a runtime one (as Assert does). And it also has the benefit of working 
(at least if we use the old syntax) on Ada 83 compilers and Ada 95 compilers 
that never implemented the goofy Ada 95 'Size rules [i.e. Janus/Ada 95].

> OK, now we have a 2-bit type.  But we have to specify 2 bits again
> in the rep clause:
>
>         Gap1 at 0 range 1..2;

            Gap1 at 0 range 1 .. Gap1_Size;

or to be even more general:

           Gap1 at 0 range Gap1_Start .. Gap1_Size - Gap1_Start + 1;

(We have a number of lines like this in Claw and other programs here.)

 I understand the complaint here, but I still think that explictly 
specifying the bit packing in this way is best. The syntax that requires 
mentioning both the low and high bits is overkill, but that has nothing to 
do with this particular issue -- it is overkill for *any* record. We really 
need an alternative shorter syntax for these lines in a record 
representation clause:

            Gap1 at 0 bit 1;

or something like that. No one ever wants to give the high bound in these 
clauses -- it's almost pointless and a real pain if it might change (note 
the most general form given above).

                       Randy.







  reply	other threads:[~2011-07-23  0:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20 10:34 Should representation clauses be complete for each bit? okellogg
2011-07-20 14:51 ` Robert A Duff
2011-07-20 15:24   ` Georg Bauhaus
2011-07-20 17:28     ` Robert A Duff
2011-07-21  7:37       ` Martin
2011-07-21  8:22         ` Simon Wright
2011-07-21 14:58           ` Robert A Duff
2011-07-23  0:13             ` Randy Brukardt [this message]
2011-07-27 14:12               ` okellogg
2011-07-28  0:03                 ` Randy Brukardt
2011-07-21  9:43         ` Georg Bauhaus
2011-07-21 15:06           ` Robert A Duff
2011-07-31 15:02             ` BrianG
2011-07-21 21:11           ` Brian Drummond
2011-07-21  7:59     ` Stephen Leake
2011-07-20 15:29   ` okellogg
2011-07-20 16:24     ` Dmitry A. Kazakov
2011-07-20 16:58       ` okellogg
2011-07-20 19:38         ` Dmitry A. Kazakov
2011-07-20 17:27     ` Robert A Duff
2011-07-20 19:14       ` okellogg
2011-07-20 20:13         ` J-P. Rosen
2011-07-20 21:23           ` Robert A Duff
2011-07-20 21:21         ` Robert A Duff
2011-07-21  8:02         ` Stephen Leake
2011-07-21  8:00     ` Stephen Leake
2011-07-21  7:36   ` Martin
2011-07-22 23:50   ` Randy Brukardt
2011-07-23  2:16     ` tmoran
2011-07-23 15:12     ` Robert A Duff
2011-07-26 21:10       ` Randy Brukardt
2011-07-23  0:01   ` Randy Brukardt
  -- strict thread matches above, loose matches on Subject: below --
1998-04-17  0:00 Should Representation Clauses " Marin David Condic, 561.796.8997, M/S 731-96
     [not found] <3533C3C5.3F25CB91@cacd.rockwell.com>
1998-04-16  0:00 ` Stephen Leake
replies disabled

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