* Adjust bug?
@ 1997-07-18 0:00 Tom Moran
1997-07-18 0:00 ` Tucker Taft
0 siblings, 1 reply; 2+ messages in thread
From: Tom Moran @ 1997-07-18 0:00 UTC (permalink / raw)
This test program assigns the 'controlled' result from a function
to a variable. Two compilers create an intermediate anonymous object
and copy and adjust to it before copying and adjusting to the final
result. The third compiler does only the final adjust. Is this
legal according to 7.6(21)? Making the component 'id' aliased does
not change the behavior. The result is that the anonymous object
is eventually Finalized without ever having been Initialized or
Adjusted,
with sad results for my program. Is this a bug in the third compiler,
or a legal (though unfortunate) possibility?
with ada.finalization;
package testc is
type c_type is new ada.finalization.controlled with record
id:integer:=0;
end record;
function create return c_type;
procedure initialize(x:in out c_type);
procedure adjust (x:in out c_type);
procedure finalize (x:in out c_type);
end testc;
with ada.text_io;
with ada.unchecked_conversion;
package body testc is
type a is access all c_type;
function showa is new ada.unchecked_conversion(a,long_integer);
function create return c_type is
newborn:aliased c_type;
begin
ada.text_io.put_line("creating" & integer'image(newborn.id) &
long_integer'image(showa(newborn'unchecked_access)));
newborn.id:=7;
return newborn;
end create;
count:natural:=0;
procedure initialize(x:in out c_type) is
begin
count:=count+1;x.id:=count;
ada.text_io.put_line("init"
& integer'image(x.id) &
long_integer'image(showa(x'unchecked_access)));
end initialize;
procedure adjust (x:in out c_type) is
begin
ada.text_io.put_line("adj"
& integer'image(x.id) &
long_integer'image(showa(x'unchecked_access)));
end adjust;
procedure finalize(x:in out c_type) is
begin
ada.text_io.put_line("fin"
& integer'image(x.id) &
long_integer'image(showa(x'unchecked_access)));
end finalize;
end testc;
with ada.text_io,testc;
procedure test is
procedure try is
my_c:testc.c_type;
begin
ada.text_io.put_line("set");
my_c:=testc.create;
ada.text_io.put_line("did it");
end try;
begin
ada.text_io.put_line("start");
try;
ada.text_io.put_line("done");
end test;
two compilers questionable compiler
start start
init 1 39318880 init 1 5897228
set set
init 2 39318744 init 2 5897016
creating 2 39318744 creating 2 5897016
adj 7 73084948 fin 1 5897228
fin 7 39318744 adj 7 5897228
fin 1 39318880 fin 7 4587648
adj 7 39318880 did it
fin 7 73084948 fin 7 5897228
did it done
fin 7 39318880
done
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Adjust bug?
1997-07-18 0:00 Adjust bug? Tom Moran
@ 1997-07-18 0:00 ` Tucker Taft
0 siblings, 0 replies; 2+ messages in thread
From: Tucker Taft @ 1997-07-18 0:00 UTC (permalink / raw)
Tom Moran (tmoran@bix.com) wrote:
: This test program assigns the 'controlled' result from a function
: to a variable. Two compilers create an intermediate anonymous object
: and copy and adjust to it before copying and adjusting to the final
: result. The third compiler does only the final adjust. Is this
: legal according to 7.6(21)?
Yes, it does seem to be legal, provided that the type
does not have aliased subcomponents. Declaring the object as
a whole as aliased does not inhibit the 7.6(21) optimizations; only
the presence of aliased subcomponents does that.
: ... Making the component 'id' aliased does
: not change the behavior.
If a controlled object has an aliased subcomponent, then it should
not be moved without being re-adjusted. However, int the
code that follows, you have made the object as a whole
aliased, but you did not declare the component "id" aliased.
Have you tried this with "aliased" on the declaration of "id"
itself, as opposed to on the declaration of the object "newborn"?
It is certainly the case that this compiler is moving the
object newborn to a new location (from 5897016 to 4587648)
without re-adjusting it, but that is permitted since it has
no aliased subcomponents.
However, if you try this again and you add the word "aliased"
to the declaration of the "id" component, then you should
see different behavior, or else the compiler would be violating
the last sentence of 7.6(21).
: ... The result is that the anonymous object
: is eventually Finalized without ever having been Initialized or
: Adjusted,
: with sad results for my program. Is this a bug in the third compiler,
: or a legal (though unfortunate) possibility?
This is not a bug, unless you have tried this with "aliased" in the
component declaration for "id".
By the way, why are the results "sad" for your program? It may be
that what you are doing is generally not portable. However,
by declaring one of the components as aliased, you perhaps can
make it portable (presuming the compiler properly honors the
last sentence of 7.6(21)).
Alternatively, you might want to change the way you are using
the various Initialize/Adjust/Finalize operations. In particular,
remember that "Initialize" is only used for default initialization
(it might better have been called "Default_Initialize"), and that
an aggregate is a way of constructing a controlled object that
doesn't result in either a call on (default) Initialize or Adjust
for the whole object. (One reason why controlled types should
always be private, is that you want to be sure that aggregates
are only used inside the definition of the controlled
abstraction.)
: with ada.finalization;
: package testc is
: type c_type is new ada.finalization.controlled with record
: id:integer:=0;
: end record;
: function create return c_type;
: procedure initialize(x:in out c_type);
: procedure adjust (x:in out c_type);
: procedure finalize (x:in out c_type);
: end testc;
: with ada.text_io;
: with ada.unchecked_conversion;
: package body testc is
: type a is access all c_type;
: function showa is new ada.unchecked_conversion(a,long_integer);
: function create return c_type is
: newborn:aliased c_type;
: begin
: ada.text_io.put_line("creating" & integer'image(newborn.id) &
: long_integer'image(showa(newborn'unchecked_access)));
: newborn.id:=7;
: return newborn;
: end create;
: count:natural:=0;
: procedure initialize(x:in out c_type) is
: begin
: count:=count+1;x.id:=count;
: ada.text_io.put_line("init"
: & integer'image(x.id) &
: long_integer'image(showa(x'unchecked_access)));
: end initialize;
: procedure adjust (x:in out c_type) is
: begin
: ada.text_io.put_line("adj"
: & integer'image(x.id) &
: long_integer'image(showa(x'unchecked_access)));
: end adjust;
: procedure finalize(x:in out c_type) is
: begin
: ada.text_io.put_line("fin"
: & integer'image(x.id) &
: long_integer'image(showa(x'unchecked_access)));
: end finalize;
: end testc;
: with ada.text_io,testc;
: procedure test is
: procedure try is
: my_c:testc.c_type;
: begin
: ada.text_io.put_line("set");
: my_c:=testc.create;
: ada.text_io.put_line("did it");
: end try;
: begin
: ada.text_io.put_line("start");
: try;
: ada.text_io.put_line("done");
: end test;
: two compilers questionable compiler
: start start
: init 1 39318880 init 1 5897228
: set set
: init 2 39318744 init 2 5897016
: creating 2 39318744 creating 2 5897016
: adj 7 73084948 fin 1 5897228
: fin 7 39318744 adj 7 5897228
: fin 1 39318880 fin 7 4587648
: adj 7 39318880 did it
: fin 7 73084948 fin 7 5897228
: did it done
: fin 7 39318880
: done
--
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Burlington, MA USA
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1997-07-18 0:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-07-18 0:00 Adjust bug? Tom Moran
1997-07-18 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox