tags:

views:

120

answers:

4

I have two ada files shown below

A1.ada

procedure KOR616 is

   I : Integer := 3;

   procedure Lowest_Level( Int : in out Integer );
   pragma Inline( Lowest_Level );

   procedure Null_Proc is
   begin
      null;
   end;

   procedure Lowest_Level( Int : in out Integer ) is
   begin
      if Int > 0 then
         Int := 7;
         Null_Proc;
      else
         Int := Int + 1;
      end if;
   end;

begin
   while I < 7 loop
      Lowest_Level( I );
   end loop;
end;

Next shown below is B1.ada

procedure Lowest_Level( Int : in out Integer );
pragma Inline( Lowest_Level );

procedure Lowest_Level( Int : in out Integer ) is

   procedure Null_Proc is
   begin
      null;
   end;

begin
   if Int > 0 then
      Int := 7;
      Null_Proc;
   else
      Int := Int + 1;
   end if;
end Lowest_Level;

with Lowest_Level;
procedure KOR618 is

   I : Integer := 3;

begin
   while I < 7 loop
      Lowest_Level( I );
   end loop;
end;

Now my doubt is is there any difference between these two files?

Thanks Maddy

+1  A: 

In B1, Null_Proc isn't inlined. (It is not within Lowest_Level).

rursw1
@rursw1--I am sorry,but i didnt get it.Can you please explain?
maddy
@rursw1: I'm confused; in `B1`, `Null_Proc` appears to be nested in `Lowest_Level`.
trashgod
Good point. There's no `pragma inline` that applies to `Null_Proc` in the first example. In the second, in order to inline the outer routine, logically it would have to inline the inner one as well.
T.E.D.
+1  A: 

In A1, procedure Null_Proc is not nested in procedure Lowest_Level; in B1, it is nested in procedure Lowest_Level. Regarding pragma Inline, "an implementation is free to follow or to ignore the recommendation expressed by the pragma." I'd expect the in-lining of nested subprograms to be implementation dependent.

trashgod
That's why I never bother with `pragma inline` unless there is a **proven** need for it. "this code has to be fast" is not good enough. Your explanation had better be of the form: "without the inline it was generating code that did X. With it, it instead did Y".
T.E.D.
+2  A: 

As written, KOR616 (A1) and KOR618 (B1) are going to have the same effect. The difference is a matter of visibility (and the compiled code will be different, of course, but I doubt that matters).

In A1, the bodies of both Null_Proc and Lowest_Level can see I, but nothing outside KOR616 can see them. Also, the body of KOR616 can see Null_Proc.

In B1, Lowest_Level (but not Null_Proc) is visible to the whole program, not just KOR618.

Simon Wright
+1  A: 

Well, the main difference is that in the second example Null_Proc is unavailable outside of Lowest_Level. In the first example, if you felt like it later you could have KOR618 or any other routine you might add later also call Null_Proc.

Generally I don't define routines inside other routines like that unless there is some reason why the inner routine makes no sense outside of the outer routine. The obvious example would be if the inner routine operates on local variables declared in the outer routine (without passing them as parameters).

In this case Null_Proc is about as general an operation as it gets, so I don't see any compelling reason to squirel it away inside Lowest_Level like that. Of course, it doesn't do anything at all, so I don't any compelling reason for it to exist in the first place. :-)

T.E.D.
I expect Maddy has removed irrelevant detail in Null_Proc.
Simon Wright