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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cca!mirror!ishmael!ada-uts!stt
From: stt@ada-uts
Newsgroups: comp.lang.ada
Subject: Re: Why one TYPE instead of the other?
Message-ID: <57900046@ada-uts>
Date: Fri, 2-Oct-87 16:33:00 EDT
Article-I.D.: ada-uts.57900046
Posted: Fri Oct  2 16:33:00 1987
Date-Received: Sat, 10-Oct-87 12:37:07 EDT
References: <23613@ucbvax.Berkeley.EDU>
Nf-ID: #R:ucbvax.Berkeley.EDU:-2361300:ada-uts:57900046:000:955
Nf-From: ada-uts!stt    Oct  2 16:33:00 1987
List-Id: <comp.lang.ada>


The first form selects an underlying implementation
based on the range, which must be specified via *static*
expressions.   This form may fail at compile-time if
the requested range cannot be supported by any predefined
type.

The second form specifies that predefined INTEGER
be used as the underlying implementation type,
and the range may be specified by arbitrary, potentially
run-time, INTEGER expressions.
This form will never fail at compile-time, but
may raise Constraint_Error at run-time if the range you
specify is outside of Integer'FIRST .. Integer'LAST.

Based on the above characteristics, the first form
is preferable when legal, since it is not dependent
on the relative sizes of the various predefined integer types,
and detects out-of-range problems at compile-time.

But as noted, it cannot be used if the desired bounds
are not static (which implies compile-time-known) expressions.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MASS