|
|||
|
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 |
|
|
||||
|
||||
|
|
|
|||
|
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. |
|
|||
|
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 |
|
|||
|
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 |
|
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|
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 |