comp.lang.ada
 help / color / mirror / Atom feed
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: Using Global Variables
Date: Fri, 18 Sep 92 08:12:45 CDT	[thread overview]
Message-ID: <9209181312.AA24702@efftoo.boeing.com> (raw)

If you're communicating between two CPUs on a common backplane and
your Ada doesn't have multi-CPU-board tasking, then if you want to
communicate between the boards, you're going to have to (a) use some
OS service (e.g., sockets), or (b) pucker up and stick the variable
into common memory.

There are "nice" and "naughty" ways to do this, of course.  Bad
boys and girls declare a data object in a package spec.  In fact,
*really* bad boys and girls declare data objects in package specs
even when they don't need to talk between CPUs.

Now Trey Haddad (ghaddad@lmsc.lockheed.com) sez:

>   Aww, c'mon guys.  I was under the impression that, in Ada, there's no
>   such animal as a 'global' variable.  There's just 'more' and 'less' local
>   variables.  What's wrong (or difficult, or complicated) about a variable
>   which is in scope in the principal subprogram?  Assuming your particular
>   application calls for it, that is.

It's true that you don't *have* to WITH a package with a data object
in the package spec, so the variable is only *potentially* global -- in
the sense that in F*rtr*n you don't *have* to reference a COMMON block,
but that seems to me to be splitting hairs.

As you can tell, I'm a real bigot about data flow control -- pass your
data in your subprogram arguments OR DIE!

Which is why I wonder about designs that use common memory "for speed".
Did these designs begin as data-flow-controlled designs, and the
common memory was retrofitted when the speed *actually* was too slow?
It's hard to complain about that (though, as a dataflow bigot, I've
found that I could always weed a lot of dumb things out of my code
before having to start on weeding out the smart things).

Or did these designs begin as vintage "working" Fortran code that used
COMMONs and there wasn't program time or money enough to redevelop, just
recode?  Or is it the programmer him/herself who isn't able to take
the time to understand and control the data flow in the system?
Those things may be facts of life in the real world, but IMHO they
should be approached apologetically (I'm a good designer, but I wasn't
allowed to be this time) rather than as justifications (Yeah, I use
COMMON -- so what?  It's great design!).

But, like I said, I'm a bigot.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

             reply	other threads:[~1992-09-18 13:12 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-09-18 13:12 crispen [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-09-29 15:05 Using Global Variables Charles H. Sampson
1992-09-28 20:56 crispen
1992-09-28 15:53 Victor Giddings
1992-09-28 14:51 Jeffrey Stewart
1992-09-28 12:52 crispen
1992-09-25 22:58 netcomsv!iscnvx!news
1992-09-25 21:16 Charles H. Sampson
1992-09-25 17:50 Charles H. Sampson
1992-09-25 17:36 Charles H. Sampson
1992-09-25 16:30 David A. Hasan
1992-09-25 14:01 crispen
1992-09-24 20:02 netcomsv!iscnvx!news
1992-09-24 18:10 crispen
1992-09-24  6:51 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!utcsri!geac!torsqnt!uuno
1992-09-24  3:52 Michael Feldman
1992-09-23 21:13 haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.ed
1992-09-23 19:11 Charles H. Sampson
1992-09-23 15:01 crispen
1992-09-23 14:26 munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!phillip.edu.au!x01233
1992-09-23 14:19 crispen
1992-09-23 13:24 wupost!spool.mu.edu!olivea!bu.edu!inmet!inmet!shafer
1992-09-23  2:44 Holmes S. Liao
1992-09-22 20:14 LEE MARDEN
1992-09-22 17:08 dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co
1992-09-22 14:54 van-bc!ubc-cs!destroyer!caen!spool.mu.edu!umn.edu!The-Star.honeywell.com!
1992-09-22 12:19 Robert Firth
1992-09-21 21:30 fred j mccall 575-3539
1992-09-21 20:58 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!spool.mu.edu
1992-09-21 20:37 Michael Feldman
1992-09-21 20:36 Michael Feldman
1992-09-21 20:31 Michael Feldman
1992-09-21 19:23 Robert Firth
1992-09-21 18:32 agate!linus!linus.mitre.org!mwvm.mitre.org!M19481
1992-09-21 16:51 Doug Smith
1992-09-21 14:43 haven.umd.edu!darwin.sura.net!spool.mu.edu!umn.edu!The-Star.honeywell.com
1992-09-21 11:49 cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd
1992-09-21  8:10 paul goffin
1992-09-21  4:08 cis.ohio-state.edu!news.sei.cmu.edu!lph
1992-09-19  2:28 Michael Feldman
1992-09-18 23:52 Charles H. Sampson
1992-09-18 22:50 Robert I. Eachus
1992-09-17 18:34 Charles H. Sampson
1992-09-17 14:24 kronos.arc.nasa.gov!iscnvx!news
1992-09-16 17:47 agate!linus!linus.mitre.org!mwvm.mitre.org!M19481
1992-09-16 15:26 Charles H. Sampson
replies disabled

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