Re: MODULEand USE versus Argument Passing
- From: Richard E Maine <nospam@xxxxxxxxxxxxx>
- Date: Wed, 29 Jun 2005 14:49:39 -0700
In article <d9us2s$ncr$1@xxxxxxxxxxxxxxxxxx>,
"E. Robert Tisdale" <E.Robert.Tisdale@xxxxxxxxxxxx> wrote:
> Global variables are *always* a bad idea.
> Never pass function arguments through modules or common storage.
I disagree with the above... but something about this sounds familiar. I
think I remember a fruitless debate about this before, so I won't follow
up further after expressing my disagreement. Lack of further reply by me
does not indicate agreement. (Besides which, I'm about to run off on a 3
week vacation without computer, which is likely to help my resolve not
to get sucked back into an extended debate on this).
The "always" and "never" are the parts that I most disagree with. If
this had been phrased in less extreme terms, I'd not have felt any
reason to reply. But there are *VERY* few programming style guidelines
where I think that the use of the words "always" or "never" are
justified. I wouldn't even go so far as to seriously say "never say
never". :-) But one should say it darned rarely.
I think I recall from an earlier thread that I was surprised to find
that Robert meant his "always" and "never" here quite literally and
seriously. If so, then I don't see it worth even arguing the point. I
will just register my disagreement and stop.
> There is almost nothing
> that modern computers do faster than [subprogram] calls.
> You won't be able to measure the time that your function
> spends on subprogram calls unless the subprogram does nothing.
> If your subprogram has more than a few arguments,
> you probably have a design problem.
> If some of the arguments can be grouped into larger objects,
> create a derived type which contains them...
Hmm. So you should never pass data any other way than by arguments, but
you shouldn't have very many arguments either? Ok, and the solution to
this apparent conundrum is to marshall the data into a few derived-type
objects? Sounds to me like the calling procedure is going to have a lot
of overhead in building special-purpose derived types and copying data
into and out of them. This seems like a burden both in terms of code
bloat and performance, which sounds to me like it contradicts the claim
that the overhead for subroutine calls is negligible; perhaps that's
because I'd include the visible overhead involved in organizing the data
rather than restricting myself purely to the overhead of the literal
CALL and RETURN statements.
Maybe the assumption here is that good design will somehow keep one from
having to make different derived types for different subroutines. One
certainly *COULD* do this by putting essentially every variable needed
by any procedure all in the same huge derived type object and passing
that to everything. But I'd tend to view that as a way of making
everything essentially global under a different guise. Maybe that
doesn't count as "global".
More likely is that I don't understand at all how to properly apply
Robert's suggestion to programs of substantial size and complexity. :-(
Again, the concept of grouping related things into derived types is one
that I agree with and regularly use. But I don't agree that it is a
panacea for this issue - just one possible tool.
The short version is that I disagree with pretty much everything that
Robert said here. While I recognize a few underlying concepts, I
disagree with the end recommendations.
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