Re: objectiveC/C question

[Rick Riolo]

marcus,
thanks for the info.
alas, I do recall fortran and its commons...that's
where the term tragedy of the commons came from, right? ;-)
Anyway...
I didn't realize gcc under unix was going to do that to/for me.

re the extern: presumably I have to have one global (and common'd?)
declaration for the extern'd items to be linked to
though, yes?  Or does it make it 'common' only if it finds
multiple global definitions?

thanks again.
 -r 


Rick Riolo                           address@hidden
Center for Study of Complex Systems (CSCS)
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 5 Feb 2000, Marcus G. Daniels wrote:

> Date: 05 Feb 2000 12:39:00 -0800
> From: Marcus G. Daniels <address@hidden>
> Reply-To: address@hidden
> To: address@hidden
> Subject: Re: objectiveC/C question
> 
> >>>>> "RLR" == Rick Riolo <address@hidden> writes:
> 
> RLR> Why without 'static' storage class declaration do all those
> RLR> declared nextID's in the different *.m files get treated as one
> RLR> storage item at link time?
> 
> Most Unix systems provide and use a symbol type of `common'.  It dates
> back to common blocks in Fortran, where different modules could share
> an area of memory for respective variables, but some modules might
> grow it more than others.
> 
> So not only do you get a single piece of memory allocated for duplicate
> global variables, but the types of those global variables can be
> different, too.
> 
> I personally avoid using common variables, because when I do it is
> usually a mistake, i.e. there's an unintended namespace clash across
> module, or delaying decisions about where the variable ought to
> physically live.  -fno-common enforces that.
> 
> RLR> If that is the case, then does the 'extern' in the above example
> RLR> make any difference in this case?  (again, note it is outside of
> RLR> any method).
> 
> By using extern, you will not introduce common symbols -- just
> references. 
> 
>                   ==================================
>    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.