Go Back   Rhinocerus > Newsgroup > Newsgroup comp.lang.* 1 > Newsgroup comp.lang.fortran

Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old 03-09-2006, 06:16 PM
Joe Krahn
Guest
 
Posts: n/a
Default Initialization of local variables

Initialization defines an initial value when a variable's storage is
first allocated. A local variable in a procedure is allocated upon
calling that procedure, so it makes sense to set the initial value on
each procedure call, except for variables with the SAVE attribute.
Fortran sort of follows this idea, except that initialized locals get an
implicit SAVE attribute.

Is there a good rationale for this behavior, or is it more historical?

After compiling, initialization at every instance is the same as
declaration followed by assignment, so writing it out that way sort of
makes sens. But, it is a bit confusing if you write Fortran and C. Maybe
a NOSAVE would be useful. (Except perhaps that some people would start
promoting the idea of having SAVE or NOSAVE on every variable.)

Thanks,
Joe Krahn
Reply With Quote
Alt Today
Advertising
 
and become member of Rhinocerus
Standard Sponsored Links

  #2 (permalink)  
Old 03-09-2006, 07:13 PM
jwm
Guest
 
Posts: n/a
Default Re: Initialization of local variables

I think the behavior is more historical than practical. Some compilers
(e.g., DEC-like, Absoft), have the keyword AUTOMATIC (as opposite to
STATIC), which indeed excludes the implicit use of the SAVE attribute.

Reply With Quote
  #3 (permalink)  
Old 03-09-2006, 07:42 PM
Richard E Maine
Guest
 
Posts: n/a
Default Re: Initialization of local variables

Joe Krahn <krahn@niehs.nih.gov> wrote:

> Initialization defines an initial value when a variable's storage is
> first allocated. A local variable in a procedure is allocated upon
> calling that procedure, so it makes sense to set the initial value on
> each procedure call, except for variables with the SAVE attribute.
> Fortran sort of follows this idea, except that initialized locals get an
> implicit SAVE attribute.
>
> Is there a good rationale for this behavior, or is it more historical?


Yes. :-) To both parts. There is a good rationale *AND* it is at least
partly historical. You didn't think those were exclusive did you? :-)

Oh dear. This question again. :-( I'm tempted to just say to go google
it, as the question has come up here many times and tends to generate
long, repetitive threads. I hereby resolve that this time I will *NOT*
comment on various people's ideas of how they would have done things
differently or better. That's a different question, and that's the one
that tends to draw out into the long threads. I'll just stick to the
question you asked. This does not imply that I necessarily do or do not
think it is the best way for things to be.

Several sub-points.

1. Sort of a side issue, but note that there is perfectly fine
functionality for setting the value of a specific variable on each entry
to a procedure. It is called an assignment statement. I will not
participate in debates about whether it would or would not be nice to be
able to do the same thing with a different syntax.

2. Prior to f90, initialization did not imply save. You could have
initialized, nonsaved local variables. The rules had a somewhat odd
quirk if you considered them abstractly. Namely, an initialized nonsaved
variable retained its definition (just as though it were saved) as long
as nothing had redfined it during execution. But if you ever did
anything to redefine it, then that meant it would loose its definition
status on return. Eh? What's going on there?

To understand that, you have to understand it as allowing compilers
freedom to use any of several strategies. In particular, the compiler
might save the last-defined value or it might redo the initialization on
each entry. Either compiler behavior was allowed. User code was
prohibitted from doing things that would depend on which choice the
compiler made. If the variable in question was never redefined in the
executable code (i.e. if it was a constant value that just happened to
be stored in a variable - very common for arrays in particular, as
parameters could not be arrays in f77), then either implementation would
give the same value, so the user was allowed to depend on that. If the
variable were initialized to one value and then redefined to another
one, you would get a different value on the second entry depending on
which implementation strategy were used. SO the standard said the
variable became undefined (which meant that looking at the value made
your code nonstandard).

That was the idea. And I might add that there in fact *WERE*
implementations that used both strategies; I used some. Most f77
compilers allocated pretty much everything statically (and initialized
only once), but that was not true of all of them.

However... by the time f90 was comming out, pretty much all compilers
did allocate at least initialized locals statically. And programs
depended on this in practice. Lots of programs. Such programs were
nonstandard, but widespread.

3. F90 added the initialization implies save. The basic rationale went
something like... a) lots of existing programs assume it anyway b)
compilers are going to keep doing it because otherwise they will break
all those programs that assume it. There was perhaps also a small
element of c) we don't need reinitialization on each entry because
assignment statements do that. But I'm pretty sure that a+b were the big
points.

In regard to 3a, you might find some people claiming that the existing
programs might intend something different. Well, that's just not
supportable in practice. Perhaps some people today might look and think
that they would mean something different by that, but in the huge
preponderance of actual existing programs, SAVE was intended - perhaps
not by that name because perhaps the programmer didn't even know the
term, but that's the functionality intended. If this hadn't been the
intent, the programs wouldn't have worked. Ok, perhaps some did intend
otherwise and were buggy as a result, but I'm talking about the existing
programs that actually worked correctly.

So in essense, the initialization-implies-save rule was acknowledgement
of existing practice, making those codes that depended on it
standard-conforming (at least in that regard).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Reply With Quote
  #4 (permalink)  
Old 03-09-2006, 08:06 PM
glen herrmannsfeldt
Guest
 
Posts: n/a
Default Re: Initialization of local variables

Joe Krahn <krahn@niehs.nih.gov> wrote:
> Initialization defines an initial value when a variable's storage is
> first allocated. A local variable in a procedure is allocated upon
> calling that procedure, so it makes sense to set the initial value on
> each procedure call, except for variables with the SAVE attribute.
> Fortran sort of follows this idea, except that initialized locals get an
> implicit SAVE attribute.


> Is there a good rationale for this behavior, or is it more historical?


Historically, static allocation was fairly common, at least for
Fortran. That is where implied SAVE comes from.

> After compiling, initialization at every instance is the same as
> declaration followed by assignment, so writing it out that way sort of
> makes sens. But, it is a bit confusing if you write Fortran and C. Maybe
> a NOSAVE would be useful. (Except perhaps that some people would start
> promoting the idea of having SAVE or NOSAVE on every variable.)


You can put static on all your C variables.

Pre-ANSI C didn't allow initialization of automatic arrays,
so that was a common use for static.

-- glen
Reply With Quote
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: One of my reporting macros has 90 parameters - is that a record? David Newsgroup comp.soft-sys.sas 5 02-04-2006 03:07 AM
Re: Finding macro variables by means of metadata toby dunn Newsgroup comp.soft-sys.sas 2 01-12-2006 02:05 PM
Re: Creating dummy variables automatically Dale McLerran Newsgroup comp.soft-sys.sas 2 01-09-2006 11:05 AM
Re: Arranging variables Crawford, Peter1 Newsgroup comp.soft-sys.sas 0 08-18-2005 07:41 AM



All times are GMT. The time now is 05:57 AM.


Copyright ©2009

LinkBacks Enabled by vBSEO 3.3.0 RC2 © 2009, Crawlability, Inc.