Home > Archive > Fortran > October 2006 > Re: How to decide using COMMON block variables or function/subroutine parameters?
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 |
Re: How to decide using COMMON block variables or function/subroutine parameters?
|
|
| glen herrmannsfeldt 2006-10-30, 7:15 pm |
| Shawn <shaw@nospam.com> wrote:
> When I read somebody's program, I saw the function/subroutine has
> several parameters, in the meantime, the function/subroutine also use
> common block variables. It seems to me, both ways serve the purpose:
> pass in the variable values and/or get new values.
If you always pass the same variable(s) every time you
call a subprogram, and if you can't imagine ever calling it
with different variables, even 20 years from now, it might as
well go in COMMON.
If you are working on a weather simulation program, you might
have a big three-dimensional array with the temperature at
different places around the earth, and at different altitudes.
Different subroutines will need this array, and do different
operations on it. They might be so specialized that there would
be no need ever to operate on a different array. If it would be
much harder to generalize the subroutine than to change to
passing the array as an argument, it might as well go in COMMON.
You might also have arrays with wind direction and air pressure
at the same points.
Any subprogram that is generally useful, such as a root finder,
integration or differential equation solver, other than as
described above, should have all variables passed as arguments.
-- glen
| |
| Richard E Maine 2006-10-30, 7:15 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
[discusses the old common vs arguments question]
While I generally agree with Glen's broad description of the criteria to
use in this selection, I would make one addendum.
From context, the question is about design issues in new code. For new
code, I would not even consider using COMMON. It comes with much
"baggage" from older days and cannot be used with some newer features of
the language (allocatable variables is one notable example; others
exist). I would use module variables instead. Glen's general guidelines
still apply, but substitute "module" wherever he said "common". At
least, that would be my advice.
--
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
| |
|
| "Richard E Maine" <nospam@see.signature> wrote in message
news:1hntchs.1e7dqx01rmuv7wN%nospam@see.signature...
> glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
>
> [discusses the old common vs arguments question]
>
> While I generally agree with Glen's broad description of the criteria to
> use in this selection, I would make one addendum.
>
> From context, the question is about design issues in new code. For new
> code, I would not even consider using COMMON. It comes with much
> "baggage" from older days and cannot be used with some newer features of
> the language (allocatable variables is one notable example; others
> exist). I would use module variables instead. Glen's general guidelines
> still apply, but substitute "module" wherever he said "common". At
> least, that would be my advice.
>
A word of caution. Unlike COMMON, you can easily get stuck in circular
refernce hell if you exclusively use module data rather than procedure
arguments. In the following code snippet there is a circular reference
because of the use of module associated data.
module a
contains
subroutine foo_a()
use module b, only: j
integer :: i
i = j
end subroutine foo_a
end module a
module b
integer :: j
contains
subroutine foo_b()
use module a, only: foo_a
call foo_a()
end subroutine foo_b
end module b
In this version the circular reference is broken by using a procedure
argument in foo_a.
module a
contains
subroutine foo_a(j)
integer, intent(in) :: j
integer :: i
i = j
end subroutine foo_a
end module a
module b
integer :: j
contains
subroutine foo_b()
use module a, only: foo_a
call foo_a(j)
end subroutine foo_b
end module b
Of course you could have put j in a 3rd module, but this is often a rather
inelegant solution in my view. But sometimes it seems to be the only way of
getting rid of those pesky circular references.
Paul Holden
| |
| Richard E Maine 2006-10-30, 7:15 pm |
| PJH <abc@hotmail.com> wrote:
> A word of caution. Unlike COMMON, you can easily get stuck in circular
> refernce hell if you exclusively use module data rather than procedure
> arguments.
True. But I quibble with the "unlike COMMON" wording because of a
possible misinterpretation in the context of this as a followup to my
recommendation to use modules instead of common. It is true that this
can't happen with common, but then this also won't happen in a
straightforward translation of common data into module data. So this
isn't an argument for using common instead of modules. It is a good
point about using modules, but not a reason to prefer common. I post
this followup just to clarify that point in case it might have been
misunderstood by some.
--
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
|
|
|
|
|