[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: static vars
From: |
Rick Riolo |
Subject: |
Re: static vars |
Date: |
Mon, 28 Sep 1998 17:48:07 -0400 (EDT) |
I think I begin to see what you want.
I think you want static in a method to act like static in a function,
*except* you also want it to be unique for each instance...is that it?
I don't know what the specs for objective-C say about
static storage inside methods, but I'd be surprised
if it would say its supposed to be unique for each instance.
So I'm not so sure this is a problem with a particular implementation.
- r
Rick Riolo address@hidden
Program for Study of Complex Systems (PSCS)
4477 Randall Lab
University of Michigan Ann Arbor MI 48109-1120
Phone: 734 763 3323 Fax: 734 763 9267
http://www.pscs.umich.edu/PEOPLE/rlr-home.html
On Mon, 28 Sep 1998, donalson wrote:
> Date: Mon, 28 Sep 1998 14:34:13 -0700
> From: donalson <address@hidden>
> To: address@hidden
> Subject: Re: static vars
>
> Sorry,
>
> My last post wasn't clear, it was just a warning to Cygnus users.
> The background is this:
>
> I realized that I had a Swarm "movie player" if I just played my data
> files back through my simulation (with some slight mods to my sim.) In
> fact it needed only one object, plus model and observer. It also helped
> solve a second problem. I have a HUGH amount of data per sim run, one
> file for each of 440 cells and each cell saves 61 variables per time step
> for 3000 timesteps. I use the data player to also make stripped down data
> sets of particular variables I am investigating.
>
> Agents can enter or leave cells to 20 nearest neighbors and I keep track
> of where they come from and where they go. Unfortunatly, rather stupidly,
> I keep a running sum instead of just the number per time step. The
> obvious solution to this is to read in the array (size 20 ints) save it,
> read in the same array for the next time step, subtract them, and then
> save the new array as the old, and repeat.
>
> I started by making "oldData[20]" static, but I discovered that the data
> in it was getting changed from one iteration to the next. I could verify
> that it was correct just prior to exiting the method, but at next access,
> it had changed. It is not improbable that this is caued by mishandling of
> static vars when there are multiple insances of the same object. This is
> just a guess but the incorrect data was all within the expected range of
> the variables, just the incorrect for that instance. I tried it with a
> single variable and found the same problem. I should note that these vars
> are not accessed outside the object, and the variable names are used
> nowhere else in the simulation.
>
> Since I needed a persistent variable, my next thought was to move the
> static variables to the object definition (removing the "static" part of
> the definition). The make consisted only of the data object (I had
> changed nothing else) and the result was that the schedule did not run!
> It went through initialization and put up the displayes and then just sat
> there.
>
> I finally got it to run correctly by doing a "make clean" prior to
> recompile. I think the moral of the story may be Cygnus has some trouble
> with static variables.
>
> Cheers,
>
> D3
>
> Marcus Daniels wrote:
>
> > >>>>> "D3" == donalson <address@hidden> writes:
> >
> > D3> It is not happening.
> >
> > What is not happening? You need to explain what you want and expect
> > to happen, identify some common reference frame, and show us the
> > suspect mechanics before we can possibly help.
> >
> > I guess you want to do some processing based on some vector state
> > change, apparently chunking from some input file, but it is hard to
> > tell with the information you've provided.
> >
> > D3> Since you and I agree on that, I have to believe that there is
> > D3> something weird in Cygnus.
> >
> > You mean contrasted against some other environment?
> >
> > ==================================
> > Swarm-Support is for discussion of the technical details of the day
> > to day usage of Swarm. For list administration needs (esp.
> > [un]subscribing), please send a message to <address@hidden>
> > with "help" in the body of the message.
> > ==================================
>
> --
> *********************************************************************
> * Doug Donalson Office: (805) 893-2962
> * Ecology, Evolution, Home: (805) 961-4447
> * and Marine Biology email address@hidden
> * UC Santa Barbara
> * Santa Barbara Ca. 93106
> *********************************************************************
> *
> * The most exciting phrase to hear in science, the one that
> * heralds new discoveries, is not "EUREKA" (I have found it) but
> * "That's funny ...?"
> *
> * Isaac Asimov
> *
> *********************************************************************
>
>
>
> ==================================
> Swarm-Support is for discussion of the technical details of the day
> to day usage of Swarm. For list administration needs (esp.
> [un]subscribing), please send a message to <address@hidden>
> with "help" in the body of the message.
> ==================================
>
==================================
Swarm-Support is for discussion of the technical details of the day
to day usage of Swarm. For list administration needs (esp.
[un]subscribing), please send a message to <address@hidden>
with "help" in the body of the message.
==================================