Re: Avoiding constraint checks w/ 'Base
- From: "Randy Brukardt" <randy@xxxxxxxxxxxxxx>
- Date: Thu, 8 Dec 2005 21:11:04 -0600
"Anonymous Coward" <anonymous@xxxxxxxxxx> wrote in message
news:AL5mf.14882$H84.243@xxxxxxxxxxx
> In article <1134065313.469475.267400@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> Matthew Heaney wrote:
> >
> > So for example, if T is:
> >
> > type T is 1 .. 42;
> >
> > then T'Base is
> >
> > type T'Base is -42 .. 42;
> >
> > Note that built-in operators go through the base type, and T's "+"
> > op for example is implicitly declared as:
> >
> > function "+" (L, R : T'Base) return T'Base;
> >
> > There are no constraint checks on T'Base, so for example:
> >
> > declare
> > O1 : T := T'(1) + T'(2);
> > O2 : T'Base := T'(1) + T'(2)
> > begin
> >
> > then in the first assignment to O1, there is a constraint check to
> > ensure that the result of 1 + 2 is in the range of T, but in the
> > second assignment to O2, there is no check.
>
> I like the idea of avoiding constraint checks - especially when I know
> the result will be in range. Even if I can't be sure that the sum of
> the two operands is in range, it would be an advantage to be able to
> handle the situation without throwing an exception.
>
> So I have some questions. In your example, based on what you've said
> the ARM guarantees about minimal T'Base ranges, why would the
> initialization for O2 go unchecked, knowing that it could just as well
> go out of bounds? Is the 'Base attribute also code for "trust me, I
> know what I'm doing?"
It's won't. The "+" operation is required to check for overflow, and if the
result isn't in the range of T'Base, that check will fail. OTOH, the
*assignment* into O2 can never fail; if "+" has generated a value, it has to
fit in O2. (Compilers are allowed to store the larger value somewhere rather
than raising an exception -- this allows optimizations -- but it isn't
allowed to store the *wrong* value - unless the checks are Suppressed.)
> I think it's unfortunate that the 'Base does not necessarily use the
> full object size, so we are still forced to declare a new type, like
> "T_Safe" in this example:
Compilers generally don't choose inefficient representations. So, in
practice, 'Base will use the full object size (certainly that is the
intent). But I don't know why the "full object size" matters in the example.
If you were runing on the U2200, a 6-bit integer is supported by the
hardware, and the compiler might have chosen that for the size of your
objects. In that case, the "full object size" isn't enough to hold your
intermediate result anyway. And while worrying about the U2200 is unlikely,
change the "42" in the example to "100", and then the example would work on
ObjectAda, but not on GNAT - because the "full object size" is 32 on OA, and
8 on GNAT.
Moral: to be totally portable, never depend on anything you know about the
hardware -- because it will (or could) change. Correlary: It's always better
to declare an appropriate type, than to depend on tricks with 'Base.
Randy.
.
- References:
- 'Base
- From: ada_student
- Re: 'Base
- From: Matthew Heaney
- Avoiding constraint checks w/ 'Base
- From: Anonymous Coward
- 'Base
- Prev by Date: Re: 'Base
- Next by Date: Unchecked deallocation issues
- Previous by thread: Avoiding constraint checks w/ 'Base
- Next by thread: Re: 'Base
- Index(es):
Relevant Pages
|
