Are global or persistent variables in ADA?

Are global or persistent variables in ADA?

[Brian Franklin]

  I haven't found this in any of my books on ADA. Can I have a
procedure retain it's variable value after it returns to it's calling
routine? In C  I can use STATIC in declaring such a variable.

As an alternative is it possible to have a global variable available
 to all the modules and by this I mean available to outside packages.

Re: Are global or persistent variables in ADA?

[Tom Moran]

>procedure retain it's variable value after it returns to it's calling
>routine? In C  I can use STATIC in declaring such a variable.
Yes.  Put the variable in the body of the package containing the
procedure. One assumes you aren't doing any multi-tasking.

>As an alternative is it possible to have a global variable available
> to all the modules and by this I mean available to outside packages.
This is hardly an "alternative" since it is very different.  Put the
variable in the public part of the specification part of the package
and it will be available to any other package that 'with's this one.

Re: Are global or persistent variables in ADA?

[Steve Doiel]

Brian Franklin wrote in message <35413389.46570978@news.gatech.edu>...
>  I haven't found this in any of my books on ADA. Can I have a
>procedure retain it's variable value after it returns to it's calling
>routine? In C  I can use STATIC in declaring such a variable.
>
>As an alternative is it possible to have a global variable available
> to all the modules and by this I mean available to outside packages.
>

The closest parallel to having a STATIC variable inside a procedure is to
declare the variable inside the package containing the procedure, but
outside of any procedures in that package.  Fully global variables are
declared inside of a package spec (IMHO not a good practice).

I hope this helps,
SteveD

Re: Are global or persistent variables in ADA?

[Brian Franklin]

Thanks to all who responded.

    Never mind!  I traced it to a logic error on my part.  
ADA and the GNAT compiler work  just fine.


On Sat, 25 Apr 1998 01:04:30 GMT, bf14@prism.gatech.edu (Brian
Franklin) wrote:

>  I haven't found this in any of my books on ADA. Can I have a
>procedure retain it's variable value after it returns to it's calling
>routine? In C  I can use STATIC in declaring such a variable.
>
>As an alternative is it possible to have a global variable available
> to all the modules and by this I mean available to outside packages.
>

Re: Are global or persistent variables in ADA?

[Alan E & Carmel J Brain]

Brian Franklin wrote:
> 
>   I haven't found this in any of my books on ADA. Can I have a
> procedure retain it's variable value after it returns to it's calling
> routine? In C  I can use STATIC in declaring such a variable.

Not quite, but you have a better alternative:

package SMALL_DATABASE is

  AnInteger : Integer;

end SMALL_DATABASE;


anything that with's SMALL_DATABASE is able to do anything at all with
the variable AnInteger. Read it, write to it, whatever. It's static, and
won't go away.


But... this is not always a good idea. Maybe you should have

package SMALL_DATABASE is

  function ReadInteger return Integer;

  procedure WriteInteger(Item : in Integer);

end SMALL_DATABASE;

and an appropriate body.

Maybe, and this is safer still, you should have a guardian task, so
calls are stackable, and the thing is re-usable in a multi-threaded
environment.


But often, the first version is enough. Only those packages that need to
look at/manipulate the data "with" it.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Are global or persistent variables in ADA?

[Matthew Heaney]

In article <35420cc3.0@news.pacifier.com>, "Steve Doiel"
<nospam_steved@pacifier.com> wrote:

(start of quote)
Fully global variables are
declared inside of a package spec (IMHO not a good practice).
(end of quote)

One idiom where "global" variables do make sense is in the construction of
a subsystem, a complex abstraction that comprises several packages, ie

package P is

   <this is the public interface of the abstraction>

end P;

private package P.Q is

   O : T;
   --
   -- O is a "global" variable, shared by children of P.  However, it is only
   -- global with the subsystem rooted at P.

end P.Q;

with P.Q;
package body P.R is

   ... Q.O ...

end P.R;

This is a handy technique to use when you have data shared among many
modules in a subsystem; perhaps a semaphore or something.

Another example of having a global data, not even in a private package,
would be a storage pool object.  You may decide that all access types in an
application will use a non-default storage pool that you've defined, ie

package Storage_Pools is

   type XYZ_Storage_Pool is
      new Root_Storage_Pool with ...;

   Pool : Storage_Pool;

end Storage_Pools;

As a matter a fact, I did something like this in some B-trees I just wrote. 
One technique I like to use is to pass in a storage pool object to a
dynamic memory manager abstraction, ie

with System.Storage_Pools;

generic

   System_Storage_Pool : in out System.Storage_Pools.Root_Storage_Pool'Class;

package ACL.Trees.Storage.BPlus_Tree.Dynamic_G is

   pragma Elaborate_Body;

   type Dynamic_Storage_Pool is
     new Root_Storage_Pool with private;
...


package body ACL.Trees.Storage.BPlus_Tree.Dynamic_G is

   type Dynamic_Page_Access is
      access all Page_Base;

   for Dynamic_Page_Access'Storage_Pool use System_Storage_Pool;


And I instantiate it as follows:

with ACL.Trees.Storage.BPlus_Tree.Dynamic_G;

package BPlus.Storage.Dynamic is
   new BPlus.Storage.Dynamic_G (BPlus.Storage.Page_Access'Storage_Pool);
 
where I simply use the pool associated with another, already-existing
access type.


Actually, I do declare a global storage pool object, that I use to
instantiate the B-tree iteself;


with BPlus.Storage.Dynamic; use BPlus.Storage.Dynamic;

package BPlus.Storage_Pools is

   Pool : Dynamic_Storage_Pool;

end;

with Ada.Finalization;
with ACL.Trees.Storage.BPlus_Tree;

generic

   type B_Tree_Item is private;

   with function "=" (L, R : B_Tree_Item) return Boolean is <>;
...
   with package Storage is
    new ACL.Trees.Storage.BPlus_Tree
     (B_Tree_Item,
      B_Tree_Item_Array,
      B_Tree_Key,
      B_Tree_Key_Array,
      Index_Order,
      Sequence_Order);

   type B_Tree_Storage_Pool is
     new Storage.Root_Storage_Pool with private;

   Storage_Pool : in out B_Tree_Storage_Pool;  -- pass in storage pool object
 ...


with ACL.Trees.BPlus_Trees;
with BPlus.Searches;        use BPlus.Searches;
with BPlus.Storage.Dynamic;
with BPlus.Storage_Pools;

package BPlus.Trees is
  new ACL.Trees.BPlus_Trees
  (B_Tree_Item => Integer,
   B_Tree_Item_Array => Searches.B_Tree_Item_Array,
   B_Tree_Key => Integer,
   B_Tree_Key_Array => Searches.B_Tree_Key_Array,
   Index_Order => Index_Order,
   Sequence_Order => Sequence_Order,
   Storage => BPlus.Storage,
   B_Tree_Storage_Pool => BPlus.Storage.Dynamic.Dynamic_Storage_Pool,
   Storage_Pool => Storage_Pools.Pool,   -- there it is...
   Get_Key => BPlus.Get_Key);


So, from global data isn't necessarily bad, and is often required for
declaring static, system-wide data.