comp.lang.ada
 help / color / mirror / Atom feed
From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: Adjust bug? re-post
Date: 1997/07/20
Date: 1997-07-20T00:00:00+00:00	[thread overview]
Message-ID: <EDMC70.6yp.0.-s@inmet.camb.inmet.com> (raw)
In-Reply-To: 33D11675.2FDB@bix.com


Tom Moran (tmoran@bix.com) wrote:

: (It seems this post got lost - apologies if you got it twice.)

[I received the original.  Here is my original response, with some
additional comments in []s:]

: 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)).  

[In looking at your second note, I see you are trying to include
a self-reference in the object.  This was the reason why types with 
aliased subcomponents were handled specially.  So be sure that at
least one of the subcomponents is aliased, then the compiler *should*
make sure to re-adjust whenever it moves an object.  However, I happen
to have some inside information on the compiler which you are probably
using (;-), and I just checked -- it has a bug in this area.  It fails
to notice properly the presence of aliased subcomponents.  I suspect that
in the next release it will do the right thing ;-) ;-).]

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.)

[One final note -- combining self-reference with non-limited
controlled types may be stretching things a bit.  As you can see,
they require that certain "reasonable" optimizations have to be
suppressed for them to work properly.  Have you considered
using limited controlled types?  When you put things into linked
lists, you are often (though admittedly not always) thinking in terms 
of lists of identifiable "objects" rather than "values."  The basic Ada model
is that non-limited types correspond to a value-oriented view, whereas
limited types correspond to a view where there are identifiable objects.
It is also generally more efficient to have procedures rather than functions
as "constructors" for complex objects, or use functions that return 
pointers rather than values.  It would help to understand the ultimate
goal of the self-references, etc...]

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

------

: 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




      parent reply	other threads:[~1997-07-20  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-19  0:00 Adjust bug? re-post Tom Moran
1997-07-19  0:00 ` Robert Dewar
1997-07-19  0:00   ` Tom Moran
1997-07-20  0:00   ` Tom Moran
1997-07-21  0:00     ` Tucker Taft
1997-07-20  0:00 ` Tucker Taft [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox