joes@hcx2.SSD.HARRIS.COM (08/17/87)
Are renames tied to the value of the renamed variable at the time that
they are elaborated, or do they always maintain the value of the renamed
variable?
I have an example program and I can't decide what it is supposed to
do. Can anyone help?
Thanks.
Joe Schwartz
Harris Corp.
joes@HARRIS.COM
------------------------------------ cut here ----------------------------------
procedure rename is
type ptr_type is access integer;
acc : ptr_type := new integer'(1);
ren_var : integer renames acc.all; -- ren_var now equals 1
begin
acc := new integer'(10); -- change its value behind it's back
-- WHAT IS ren_var's VALUE AT THIS POINT? 1 or 10?
end rename;
------------------------------------------------------------------------------brucej@hcx1.SSD.HARRIS.COM (08/17/87)
RM 8.5(3): "The elaboration of a renaming declaration evaluates the name that follows the reserved word _renames_ and thereby determines the entity denoted by this name (the renamed entity)." The RM makes it pretty clear that the value of the renamed object should be frozen at elaboration time, and that you should not expect to be able to change it's value "behind the rename's back". So the value of `ren_var' is 1.
arny@wayback.UUCP (Arny B. Engelson) (08/19/87)
In article <94700003@hcx1>, brucej@hcx1.SSD.HARRIS.COM writes: > > RM 8.5(3): "The elaboration of a renaming declaration evaluates the > name that follows the reserved word _renames_ and thereby determines the > entity denoted by this name (the renamed entity)." > > The RM makes it pretty clear that the value of the renamed object > should be frozen at elaboration time, and that you should not expect > to be able to change it's value "behind the rename's back". > > So the value of `ren_var' is 1. I'd like to add one point that may not be clear to all: The value of the new object can be changed by referencing the original object. Referencing the original example: replacing: acc := new integer'(10); with: acc.all := 10; would change the value of ren_var to 10 because ren_var and acc.all denote the same entity. Arny B. Engelson {ihnp4|bonnie|clyde}!wayback!arny
killian@nucsrl.UUCP (Scott Killian) (08/20/87)
> S nucsrl:comp.lang.ada / joes@hcx2.SSD.HARRIS.COM / 10:26 am Aug 17, 1987 / > Are renames tied to the value of the renamed variable at the time that > they are elaborated, or do they always maintain the value of the renamed > variable? > > [ etc ] > > -- WHAT IS ren_var's VALUE AT THIS POINT? 1 or 10? > >> / nucsrl:comp.lang.ada / brucej@hcx1.SSD.HARRIS.COM / 3:02 pm Aug 17, 1987 / >>The RM makes it pretty clear that the value of the renamed object >>should be frozen at elaboration time, and that you should not expect >>to be able to change it's value "behind the rename's back". > The entity, not the value, is frozen at elaboration time. When a "renames" is used for an object, both *names* now refer to the same *entity*. A renaming declaration is like aliasing, as a form of shorthand, or to resolve name conflicts (see RM 8.5, under "Notes:") RM Appendix D (Glossary) states: "Renaming declaration: A renaming declaration declares another name for an entity." The following example is given in RM 8.5: declare L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1 [LEFTMOST_PERSON is a record type -- swk] begin L.AGE := L.AGE + 1; end; In this example, the "shorthand alias" is used to change the value entity to which it refers. Changes made to "L" affect "LEFTMOST_PERSON" and v.v.: they both denote the same entity. If the renaming only used the value existing when elaborated, then the declaration a : integer := 10; b : integer renames a; would be equivalent to a : integer := 10; b : constant integer := a; which would be maintaining *two* entities, with the second initialized to the value of the first. The RM does not suggest this interpretation. The following example program was run under the Verdix Ada Development System 5.41 (4.3 BSD): with integer_io; use integer_io; with text_io; use text_io; procedure rename is type ptr is access integer; i_ptr : ptr := new integer'(1); val : integer renames i_ptr.all; begin put(val); -- original -- case 1 i_ptr.all := 5; put(val); -- after changing the entity's value -- case 2 i_ptr := new integer'(10); put(val); -- after allocating new entity new_line; end rename; This program has the following output: 1 5 5 Hmm. It looks like in one place the renamed thing is affected, yet in the other place, it is not. This is because at elaboration time, the new name is bound not to the current *value* of the entity, but to the current *entity*. In case 1, the entity referenced by 'i_ptr.all' is the same as that referenced by 'val', which happens to be a dynamically allocated integer with value 1. The value of that integer is then changed to 5, so 'val' evaluates to 5 also. In case 2, 'i_ptr' is changed, and 'i_ptr.all' now references a *new* entity, namely a new dynamically allocated integer with value 10 (which now has nothing to do with the current value of 'val'). Now, 'val' refers to the first entity (which still exists, since it was never deallocated), and 'i_ptr.all' refers to the new entity. > -- WHAT IS ren_var's VALUE AT THIS POINT? 1 or 10? 1 Scott Scott Killian Northwestern University internet: killian@eecs.nwu.edu uucp: {gargoyle, chinet, ihnp4}!nucsrl!killian