* Re: Freezing points
[not found] <leschkes.824503590@ferret>
@ 1996-02-18 0:00 ` Tucker Taft
1996-02-18 0:00 ` Robert Dewar
0 siblings, 1 reply; 2+ messages in thread
From: Tucker Taft @ 1996-02-18 0:00 UTC (permalink / raw)
Scott Leschke (leschkes@ferret.cig.mot.com) wrote:
: Could somebody out there simply and clearly enumerate all the items that
: constitute a freezing point for me.
Although I admit RM95 13.14, Freezing Rules, is not my favorite part of
the reference manual (big <grin>), it does enumerate the freezing
points, starting at paragraph 3:
1) The *end* of a declarative_part, protected_body, or declaration of
a library package/generic package.
2) A *body* causes freezing of everything declared before it in the
same declarative part.
3) Each name, expression, or range causes freezing when appearing within:
a) generic instantation (including default actuals that
are used implicitly)
b) object_declaration (that is not a deferred constant)
4) A record extension freezes its parent type
5) A static expression causes freezing of its type, etc., where it occurs
6) A non-static expression causes freezing where it occurs, unless
it is part of a default expression/name; defaults don't cause freezing
until they are "used."
: For example, from messing with GNAT it appears that a numeric subtype
: definition with a range constraint constitutes a freezing point.
: ...
: I'm assume this is all perfectly correct from an LRM standpoint but the
: freezing point stuff has me a bit confused.
A range constraint contains two expressions (in general).
Expressions cause freezing, unless they are non-static default expressions.
Hence, a range constraint freezes the type of the range (see 13.14(12))..
: Scott Leschke..................................ph: 708-632-2786
: Motorola, Inc.................................fax: 708-632-3145
: Cellular Infrastructure Group...............email: leschkes@cig.mot.com
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Freezing points
1996-02-18 0:00 ` Freezing points Tucker Taft
@ 1996-02-18 0:00 ` Robert Dewar
0 siblings, 0 replies; 2+ messages in thread
From: Robert Dewar @ 1996-02-18 0:00 UTC (permalink / raw)
To add to Tucker's comments on freezing, one thing you will find helpful
is to understand the model behind the rules. Think of code being generated
for various constructs. Now sometimes you need to know the size and
representation of something to generate code, e.g. to generate code to
initialize an object of a type. That's what the freezing is fore, before
you can generate such code for a type, it must be frozen.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1996-02-18 0:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <leschkes.824503590@ferret>
1996-02-18 0:00 ` Freezing points Tucker Taft
1996-02-18 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox