Re: meaning of "current instance"

["Matthew Heaney" <matthew_heaney@acm.org>]

In article <2hNW3.1742$dp.68215@typhoon-sf.snfc21.pbi.net> , 
tmoran@bix.com  wrote:

>>I don't think your program will even compile.
> Sorry, I tried to simplify more than was possible.
> This prints "1 1", as seems nice, but unexpected, with one compiler,
> but "5832148 1" with another compiler.  If X.J in function Init
> is replaced by X.I, then the two compilers give
> "39190036 1" and "0 1" respectively.

These results are consistent with referring to junk on the stack.


> I presume either of X.I or X.J in function Init is erroneous, right?

I'm not sure whether it's "erroneous" or a "bounded error."  Depend in
which component you refer to, your either referring to a component that
hasn't been initialized (not too bad) or to a component that hasn't been
elaborated (very bad).


> Is the Init function allowed only to reference previously initialized values
> (ie, X.I could be referenced by Init in "J : Integer := Init(T'access);"),

The version in the code I sent earlier didn't refer to any components;
it just returned a value.  That's what I recommend you do too.

That being said, the RM says record components get elaborated in the
order in which they're declared in the record (at least this is true for
tagged types).

So in your example above, it may be OK for Init to refer to component I,
because that component has definitely been elaborated.  But you're
really treading on thin ice here...


> or can
> it reference any values (seems impossible) or are there no references
> at all to initial values of the current instance that are legal?

If the record components are elaborated in their declaration order, you
may be able to take advantage of that.  But I don't know the exact
rules.


> package junk1 is
>   type T is private;
>   procedure dump(X : in T);
>   function Init(X : access T) return Integer;
>
> private
>   function Stepper return Integer;
>
>   type T  is record
>     I : Integer := Init(T'access);

Type T probably needs to be limited.  (Did this even compile?)


>     J : Integer := Stepper;
>   end record;
>
> end junk1;
>
> with ada.text_io;
> use  ada.text_io;
> package body junk1 is
>
>   Current : Integer := 0;
>
>   function Stepper return Integer is
>   begin
>     Current := Current+1;
>     return Current;
>   end Stepper;

You have to be careful about concurrency issues.  Suppose two different
tasks each declare an instance of T, and elaborate them at exactly the
same time.  The separate invocations of Stepper are likely to clobber
each other, unless you properly synchronize access to the global
variable Current (by wrapping it in a protected object).


>   function Init(X : access T) return Integer is
>   begin
>     return X.J;   -- or X.I
>   end Init;

But X.J hasn't even been elaborated yet, and X.I doesn't even have a
value.  So referring to either component is going to get you into
trouble.



>   procedure dump(X : in T) is
>   begin
>     put_line(Integer'image(X.I)
>              & Integer'image(X.J));
>   end dump;
>
> end junk1;
>
> with junk1;
> procedure junk2 is
>   x : junk1.T;
> begin
>   junk1.dump(x);
> end junk2;

"Junk" about sums it up.



--
The theory of evolution is quite rightly called the greatest unifying
theory in biology.  The diversity of organisms, similarities and
differences between kinds of organisms, patterns of distribution and
behavior, adaptation and interaction, all this was merely a bewildering
chaos of facts until given meaning by the evolutionary theory.

Populations, Species, and Evolution
Ernst Mayr