Home > Archive > Fortran > July 2006 > variable initialized as soon as delcared
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
variable initialized as soon as delcared
|
|
|
| Hi
When variable is initialized as soon as it is delcared, care must be
taken. Check following:
subroutine a()
integer :: no=0
no=no+1
print *,no
return
end
program main
do i=1,12
call a()
end do
stop
end
Results:
1
2
3
....
12
But why?
Mike
| |
| Ian Bush 2006-07-26, 4:01 am |
|
Hi Mike,
Mike wrote:
> Hi
>
> When variable is initialized as soon as it is delcared, care must be
> taken. Check following:
>
> subroutine a()
> integer :: no=0
> no=no+1
> print *,no
> return
> end
>
> program main
> do i=1,12
> call a()
> end do
> stop
> end
>
> Results:
> 1
> 2
> 3
> ...
> 12
>
> But why?
>
It's because such a variable implicitly get the save attribute. And yes, I found
this confusing when I first started to use it, and my suggestion is not to do
this until you are sure what it does.
More explicitly the value of the variable gets saved between subroutine invocations,
as you have probably worked out. Why ? Because the standard says so. If you want a way
of thinking about it, the way I do is that all Fortran initialisations are done at compile
time, NOT run time,
Ian
| |
| highegg 2006-07-26, 4:01 am |
|
Mike wrote:
> Hi
>
> When variable is initialized as soon as it is delcared, care must be
> taken. Check following:
>
> subroutine a()
> integer :: no=0
> no=no+1
> print *,no
> return
> end
>
> program main
> do i=1,12
> call a()
> end do
> stop
> end
>
> Results:
> 1
> 2
> 3
> ...
> 12
>
> But why?
>
> Mike
Did you use other language before? And which one?
I'm just curious about the answer because I have a strong feeling that
this
common misunderstanding is caused by habits from other languages, and
the feature itself is relatively logical for Fortran.
Jaroslav
| |
| beliavsky@aol.com 2006-07-26, 7:59 am |
|
Mike wrote:
> Hi
>
> When variable is initialized as soon as it is delcared, care must be
> taken. Check following:
>
> subroutine a()
> integer :: no=0
> no=no+1
> print *,no
> return
> end
>
> program main
> do i=1,12
> call a()
> end do
> stop
> end
Ian Bush's reply was correct. The subroutine you have written gives the
same output if the declaration of no is replaced with
integer, save :: no=0
, and I suggest that the "save" keyword always appear explicitly in
such cases, to remind the reader of what the code does. If you don't
want "save", instead write
integer :: no
no = 0
| |
|
|
beliavsky@aol.com =E5=AF=AB=E9=81=93=EF=BC=9A
> Mike wrote:
>
> Ian Bush's reply was correct. The subroutine you have written gives the
> same output if the declaration of no is replaced with
>
> integer, save :: no=3D0
>
> , and I suggest that the "save" keyword always appear explicitly in
> such cases, to remind the reader of what the code does. If you don't
> want "save", instead write
>=20
> integer :: no
> no =3D 0
Yes, that'll be ok.
| |
|
| the way I do is that all Fortran initialisations are done at compile
> time, NOT run time,
Could you explain more about it?
Mike
| |
| Ancient_Hacker 2006-07-26, 7:59 am |
|
Declarations in Fortran are tricky--- most of them are "static" i.e
parsed and done at compile time, just once, such as this
initialization.
But then again the dynamic ones: integer X(m,n), have to be done of
course at run-time.
It's my choice to not dare try initializing things in the declaration,
too much chance for error. how's about using the good old "data"
statement? That's pretty clear that it's done just once. I think.
Unless there's some new F90 extension I didnt read about.
| |
| Gordon Sande 2006-07-26, 7:59 am |
| On 2006-07-26 08:54:40 -0300, "Mike" <acout@yam.com> said:
> the way I do is that all Fortran initialisations are done at compile
> Could you explain more about it?
Initialization at "compile time" is the mechanism that allows a random
number generator to remember its internal status between successive
calls by a user, to pick an example that might be within your experience.
Yoy were asked about your prior programming experience because there is a
very strong impression that explaining the Fortran semantics will actually
involve having you UNLEARN the semantics of some other language.
This question comes up now and then and usually results in the comment
by the questioner of "Why doesn't Fortran do it like XXX?" Of course
Fortran is a much older language and the question should be "Why doesn't
XXX do it like Fortran?" as well as "Did you ever bother to read the manual
where it discusses initialization?". The answers are usually that "I don't
have a manual handy and in any case I am in a hurry" and "XXX is the first
language I learned."
You do get brownie points for realizing you had a problem and were
willing to ask to find out why.
> Mike
| |
| Jugoslav Dujic 2006-07-26, 7:01 pm |
| Gordon Sande wrote:
| On 2006-07-26 08:54:40 -0300, "Mike" <acout@yam.com> said:
|
|| the way I do is that all Fortran initialisations are done at compile
||| time, NOT run time,
|| Could you explain more about it?
|
| Initialization at "compile time" is the mechanism that allows a random
| number generator to remember its internal status between successive
| calls by a user, to pick an example that might be within your experience.
Nitpicking: I must say I dislike the "compile time" analogy in this context.
"Compile time" refers to an event which occurs during compilation of the
source file into the object file. It's both sufficient, and more clear, to
state that "initialization is done only once, upon variable's creation".
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
| |
| Gordon Sande 2006-07-26, 7:01 pm |
| On 2006-07-26 11:51:12 -0300, "Jugoslav Dujic" <jdujic@yahoo.com> said:
> Gordon Sande wrote:
> | On 2006-07-26 08:54:40 -0300, "Mike" <acout@yam.com> said:
> | || the way I do is that all Fortran initialisations are done at compile
> ||| time, NOT run time,
> || Could you explain more about it?
> | | Initialization at "compile time" is the mechanism that allows a random
> | number generator to remember its internal status between successive
> | calls by a user, to pick an example that might be within your experience.
>
> Nitpicking: I must say I dislike the "compile time" analogy in this context.
> "Compile time" refers to an event which occurs during compilation of the
> source file into the object file. It's both sufficient, and more clear, to
> state that "initialization is done only once, upon variable's creation".
I do not like "compile time" either which is why it is quoted. But lots of
folks seem to use the term, so it it helps them understand things I will
go with the flow.
The problem for the original poster was that he was expecting the
initialization
to be done when the variable was created and expected only one initializtion
to be done for each creation of the variable. The problem is that Fortran
semantics is that the creation is done as part of the pre-execution
initialization,
as it is called by some, and not when the unit is invoked as a result
of the implied
save attribute. The term "upon variable's creation" does not convey the
fact that
the creation is done once per program rather than once per invocation.
One expects
initialization to be done exactly once, but that leaves open the
question of once
of what? "Compile time" at least indicates that it happens before the program
starts to execute, and that happens a total of one time only, which is the
important fact here.
| |
| Ian Thompson 2006-07-26, 7:01 pm |
| Mike wrote:
> Hi
>
> When variable is initialized as soon as it is delcared, care must be
> taken. Check following:
>
> subroutine a()
> integer :: no=0
> no=no+1
> print *,no
> return
> end
>
> program main
> do i=1,12
> call a()
> end do
> stop
> end
>
> Results:
> 1
> 2
> 3
> ...
> 12
>
> But why?
>
> Mike
Mike:
This happens because Fortran doesn't destroy variables when you go
outside of their scope. Memory for static objects is allocated once
(when program execution begins), so declarations such as
integer :: no
are also applied only once, even if you specify an initial value, as above.
I imagine this yields better performance than constantly creating and
destroying local variables (at the expense of using more memory).
Regards,
Ian Thompson.
| |
| Dick Hendrickson 2006-07-26, 7:01 pm |
|
Ian Thompson wrote:
> Mike wrote:
>
>
>
> Mike:
>
> This happens because Fortran doesn't destroy variables when you go
> outside of their scope. Memory for static objects is allocated once
> (when program execution begins), so declarations such as
>
> integer :: no
>
> are also applied only once, even if you specify an initial value, as above.
That's a pretty confusing, and maybe even wrong, way
to look at it. Fortran doesn't specify one way or the
other if variables are "destroyed". Variables can have the
SAVE attribute. If they do have it, then their values are
retained when they go out of scope. If they don't have the
SAVE attribute, then their values become undefined when they
go out of scope. This has nothing to do with how or where
they are stored in memory. Most compilers use a stack for
unsaved variables and the memory comes and goes. That fits
in perfectly well with the standard.
The confusing thing in the original post was the implicit
SAVE caused by the initialization. That's an historical
artifact. SAVE, as an attribute, was introduced in F90
and, unrelated to SAVE, F90 was the first version of the
language to actually require some sort of dynamic memory
capability. Prior to that, many (probably even most)
compilers did static allocation for variables, especially
for those that were initialized with a DATA statement.
The most consistent way to enhance initialization and
require dynamic memory was to have an implicit SAVE on
the initialization statements. The OP is hardly the first
person to get  here. One of the many things F got
right was requiring the SAVE to be explicit on the
initialization statement.
Dick Hendrickson
>
> I imagine this yields better performance than constantly creating and
> destroying local variables (at the expense of using more memory).
>
> Regards,
> Ian Thompson.
| |
| glen herrmannsfeldt 2006-07-27, 4:00 am |
| Gordon Sande wrote:
(snip on initialized variables)
> I do not like "compile time" either which is why it is quoted. But lots of
> folks seem to use the term, so it it helps them understand things I will
> go with the flow.
The usual term is static, but they are pretty much done at compile
time. For the early Fortran compilers all variables were static.
For many systems, static variables are stored at the end of the code
for each subprogram, initialized or not. If initialized, the value is
stored in the same way that executable instructions are stored.
Static is a better term, but "compile time" isn't so far off.
-- glen
| |
| Ian Bush 2006-07-27, 4:00 am |
| Gordon Sande wrote:
> On 2006-07-26 11:51:12 -0300, "Jugoslav Dujic" <jdujic@yahoo.com> said:
>
>
> I do not like "compile time" either which is why it is quoted. But lots of
> folks seem to use the term, so it it helps them understand things I will
> go with the flow.
>
Snip.
> "Compile time" at least indicates that it happens before the
> program starts to execute, and that happens a total of one time only,
> which is the important fact here.
I take your point. The reason I used and use "compile time" to explain this is
as much to stress that the initialisation of the variable is performed before
the Fortran, or at least the Fortran part of the program starts to execute.
Yes it's a lie, but a fairly white one I think if it helps to explain why the
variable is initialised once, and once only.
Is there a redundancy in that last phrase ?
Ian
|
|
|
|
|