Re: Scope of implied-do index
- From: nospam@xxxxxxxxxxxxx (Richard E Maine)
- Date: Thu, 31 Aug 2006 09:14:39 -0700
Brooks Moses <bmoses-nospam@xxxxxxxxxxxxxxxxxx> wrote:
Steven G. Kargl wrote:[questions about the scope of implied DO variables]
I spent about 15 minutes tracking down why that was illegal, and then
came across section 14.1.3, which caused me to change my opinion and
consider it to be legal:
I think you found the right stuff. (And I'll admit that I didn't
carefully read and consider every sentence in your reply, but it sounds
right at a skim, so I don't think I need to).
I further conclude that this distinction between types of implied-do
loops and different rules for them is an extremely fine hair for the
standard to be splitting, and I wish to register my sense of "Eeew!" at it!
I quite agree. There was a time when I wasn't aware of the difference
and thus ended up making some completely bogus argument on the floor of
J3. I forget what argument I was making, but I recall being a bit
embarrased when my point was completely destroyed by someone making the
observation that the rules were different. I still have to be really
careful to avoid getting them backwards.
I think glenn has pointed out at least part of the reason for the
difference - a compile-time versus run-time issue. Some array
constructors can be in initialization expressions, which don't have an
execution sequence (or execution at all). I won't claim that this
explains everything, but it seems like at least part of the reason.
Anyway, that's what helps me remember (when I think it through
carefully). I agree that this doesn't make it all "obvious".
Implied DO variables with scope of the implied DO are one of my least
favorite features (along with statement function dummy arguments, which
have a similar issue, but I can avoid using statement functions). There
is no place "reasonable" to put a declaration of them, so you end up
having to put the declaration in a scope where it doesn't logically
belong. This causes all kinds of mess. For example, here's a simple case
to illustrate one of the quirks.
module my_mod
implicit none
integer :: i
real :: array(3) = [i, i=1,3]
end module my_mod
The integer declaration is required because of the implicit none (and by
my style preferences in any case). But look what ugly "side effect" it
has. I intended it only to declare the type of the implied DO variaable,
but that one declaration ends up declaring 2 things - the implied DO
variable, plus a public module variable named i. This is likely to be a
bit of a surprise to someone USEing the module and not expecting a name
conflict for such a commonly used name. Yes, I know they could avoid it
with ONLY, but I still think this is a trap. Oh, and, of course, the
darned module variable is also likely to get host associated into module
procedures, causing problems there if I intended to have a local
variable named i, but forgot to declare it. I've just generally got this
unwanted variable running around that does nothing useful, but can do
plenty of harm.
To ameliorate the harm a little, I don't use single-letter names for
implied DO variables in module scope like that, even though they are
quite common choices in other contexts. I typically use something more
like i_do to lower the odds of conflict. I also make darned sure that
the variable isn't public.
--
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
.
- References:
- Scope of implied-do index
- From: Steven G. Kargl
- Re: Scope of implied-do index
- From: Brooks Moses
- Scope of implied-do index
- Prev by Date: Re: Array puzzle
- Next by Date: Re: problematic array assignment in double precision (ifort, windows)
- Previous by thread: Re: Scope of implied-do index
- Next by thread: Re: Scope of implied-do index
- Index(es):
Relevant Pages
|
