declaration order
tho...@antispam.ham
certain declarations must appear? For example, the following code fragment
works with some compilers, but not others:
SUBROUTINE SAMPLE(ARRAY,N)
IMPLICIT NONE
REAL ARRAY(N)
INTEGER N
Some compilers complain that in the ARRAY declaration, N does not have an
explicit type. Of course, a one-pass compiler wouldn't know about the
explicit type statement that follows because it hasn't read it yet. A
multi-pass compiler could know about the explicit type declaration for N
before dealing with the ARRAY declaration.
My own coding style orders declarations alphabetically, so the above can
and does appear in my code, which causes problems for some compilers.
CVF 6.6c complains, gfortran does not.
Phillip Helbig---undress to reply
> Do more recent versions of the Fortran standard specify the order in which
> certain declarations must appear? For example, the following code fragment
> works with some compilers, but not others:
>
> SUBROUTINE SAMPLE(ARRAY,N)
> IMPLICIT NONE
> REAL ARRAY(N)
> INTEGER N
I think it makes the code clearer to declare variables before they are
used, not just for a one-pass compiler (or to decrease the number of
passes for a multi-pass compiler) but also for the reader of the code.
Jan Gerrit Kootstra
Dear Tholen,
In general I would avoid using variables with the same name but
different type in the same scope.
Although it might be acceptable by the standard, it will be probably be
confusing in the future for code maintainers.
Try to keep your code readable for other coders.
Kind regards,
Jan Gerrit
robin
>Do more recent versions of the Fortran standard specify the order in which
>certain declarations must appear? For example, the following code fragment
>works with some compilers, but not others:
>
>SUBROUTINE SAMPLE(ARRAY,N)
>IMPLICIT NONE
>REAL ARRAY(N)
>INTEGER N
This is old-fashioned code.
Better to define ARRAY as REAL :: ARRAY ( : )
Then you have:
SUBROUTINE SAMPLE (ARRAY)
IMPLICIT NONE
REAL :: ARRAY( : )
INTEGER :: N
N = UBOUND(ARRAY,1)
>Some compilers complain that in the ARRAY declaration, N does not have an
>explicit type. Of course, a one-pass compiler wouldn't know about the
>explicit type statement that follows because it hasn't read it yet. A
>multi-pass compiler could know about the explicit type declaration for N
>before dealing with the ARRAY declaration.
>
>My own coding style orders declarations alphabetically, so the above can
>and does appear in my code, which causes problems for some compilers.
>CVF 6.6c complains, gfortran does not.
You can avoid them (problems) as shown above.
robin
>Op 27-02-11 11:03, tho...@antispam.ham schreef:
>> Do more recent versions of the Fortran standard specify the order in which
>> certain declarations must appear? For example, the following code fragment
>> works with some compilers, but not others:
>>
>> SUBROUTINE SAMPLE(ARRAY,N)
>> IMPLICIT NONE
>> REAL ARRAY(N)
>> INTEGER N
>In general I would avoid using variables with the same name but
>different type in the same scope.
Fortran won't permit such to occur.
robin
>certain declarations must appear? For example, the following code fragment
>works with some compilers, but not others:
>
>SUBROUTINE SAMPLE(ARRAY,N)
>IMPLICIT NONE
>REAL ARRAY(N)
>INTEGER N
>
>Some compilers complain that in the ARRAY declaration, N does not have an
>explicit type. Of course, a one-pass compiler wouldn't know about the
>explicit type statement that follows because it hasn't read it yet.
That's irrelevant.
When you introduced the variables ARRAY and N in the SUBROUTINE statement,
the types aren't known until subsequent statements.
A one-pass compiler can handle that, as can multi-pass compilers.
Tobias Burnus
> Do more recent versions of the Fortran standard specify the order in which
> certain declarations must appear? For example, the following code fragment
> works with some compilers, but not others:
>
> SUBROUTINE SAMPLE(ARRAY,N)
> IMPLICIT NONE
> REAL ARRAY(N)
> INTEGER N
This order is invalid; you need to type N before:
"A variable in a specification expression shall have its type and type
parameters, if any, specified by a previous declaration in the same
scoping unit, by the implicit typing rules in effect for the scoping
unit, or by host or use association. If a variable in a specification
expression is typed by the implicit typing rules, its appearance in any
subsequent type declaration statement shall confirm the implied type and
type parameters." (F2008, 7.1.11 Speci cation expression)
> A multi-pass compiler could know about the explicit type declaration
> for N before dealing with the ARRAY declaration.
It is not as trivial as it seems to be. You can get difficult
interdependences. For instance:
subroutine foo(a, b)
implicit character (A-Z)
character(len=len(b)+1) :: a
character(len=len(a)+1) :: b
Or similar combinations where either the length, kind or the
initialization expression depends on choices made only later. Those can
get very complicated and might also be contradictory/circular dependent.
Thus, instead of allowing all unproblematic code and think hard to
reject all problematic one, the standard avoided all the problems by
requiring a proper order.
Additional note: Some compiler accept your code with default options but
reject it with some standard enforcing option. I know at least one
compiler which does so.
Tobias
Richard Maine
> Op 27-02-11 11:03, tho...@antispam.ham schreef:
> > Do more recent versions of the Fortran standard specify the order in which
> > certain declarations must appear? For example, the following code fragment
> > works with some compilers, but not others:
> >
> > SUBROUTINE SAMPLE(ARRAY,N)
> > IMPLICIT NONE
> > REAL ARRAY(N)
> > INTEGER N
> In general I would avoid using variables with the same name but
> different type in the same scope.
This doesn't do anything like that. Well, I suppose that in some sense,
because this is nonstandard code, one can't say what it does, but I've
seen the style plenty of times, and that certainly is not the intent.
The intent is that there is only one variable N. Its declaration is just
a bit late.
> Although it might be acceptable by the standard, it will be probably be
> confusing in the future for code maintainers.
No, it is not standard conforming - neither the meaning you appear to be
reading into it nor with the OP's intent.
There are limitted cases where you can have the same name identify two
entites in the same scope; this isn't even close to any of them.
(Examples include a common block and a variable of the same name, or a
generic procedure the same name as a specific one).
As to the OP's actual question, about declaration ordering, nothing has
changed significantly about that. I had to go check the f2008 standard
because I recall some discussion of greatly liberalizing such things,
but it doesn't appear to have happened. From f2008 (the words of which
look identical to f2003 to my casual glance)
"A variable in a specification expression shall have its type and type
parameters, if any, specified by a previous declaration in the same
scoping unit, by the implicit typing rules in effect for the scoping
unit, or by host or use association. If a variable in a specification
expression is typed by the implicit typing rules, its appearance in any
subsequent type declaration statement shall confirm the implied type and
type parameters."
There are some others, but that's the main one of direct relevance here.
Note that the standard could not just delete this requirement without
adding something else in its place. It might not need to be so broad; in
particular, it would not have to disallow the case you showed, but there
has to be something. WIthout some kind of ordering restriction, it is
easy to construct examples that are ill-defined because of circularity.
For a trivial example
real(kind=kind(y)) :: x
real(kind=kind(x)) :: y
They can get far more subtle than that one. I recall people (I think
Henry Zongaro was particularly good at it) comming up with some pretty
tricky examples of why some proposed relaxations of the rules stil left
ambiguities or contradictions.
I'll not critique the style choices; just sticking to the facts.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
tho...@antispam.ham
> This is old-fashioned code.
> Better to define ARRAY as REAL :: ARRAY ( : )
> Then you have:
> SUBROUTINE SAMPLE (ARRAY)
> IMPLICIT NONE
> REAL :: ARRAY( : )
> INTEGER :: N
> N = UBOUND(ARRAY,1)
I'm unfamiliar with UBOUND. When was it introduced in the standard?
Dick Hendrickson
it returns the Upper BOUND of the first dimension of array. Assumed
shape (the : dimension) is the modern way to pass arrays and UBOUND lets
you determine the hidden passed in bounds. There's a related LBOUND,
SIZE, and SHAPE set of intrinsics.
Dick Hendrickson
Colin Watters
news:ikeevo$qfv$1...@speranza.aioe.org...
2003 I think.
Problem with this advice however, is that it (the "(:)" dimension for
ARRAY) requires that the subroutine has an "Explicit Interface". This is
best achieved by putting subroutine sample into a module, and USEing the
module in the calling code. There is nothing at all wrong with doing this,
in fact I reccommend it.
...So why did I call it a "problem"?
BECAUSE, if you don't make the interface explicit, the code won't do what
you want. It may fail to compile if you're lucky, or it may crash during
execution if you are less lucky. And if you're completely out of luck, it
will run with no apparrent problem, but produce the wrong answer.
--
Qolin
Email: my qname at domain dot com
Domain: qomputing
Colin Watters
--
X"Colin Watters" <bo...@qomputing.com> wrote in message
news:ikehra$cuf$1...@news.eternal-september.org...
> <tho...@antispam.ham> wrote in message
> news:ikeevo$qfv$1...@speranza.aioe.org...
>> "robin" <rob...@dodo.com.au> writes:
>>
>>> This is old-fashioned code.
>>> Better to define ARRAY as REAL :: ARRAY ( : )
>>> Then you have:
>>> SUBROUTINE SAMPLE (ARRAY)
>>> IMPLICIT NONE
>>> REAL :: ARRAY( : )
>>> INTEGER :: N
>>> N = UBOUND(ARRAY,1)
>>
>> I'm unfamiliar with UBOUND. When was it introduced in the standard?
>>
>
> 2003 I think.
...No, sorry, as Dick says, 90.
tho...@antispam.ham
> Problem with this advice however, is that it (the "(:)" dimension for
> ARRAY) requires that the subroutine has an "Explicit Interface". This is
> best achieved by putting subroutine sample into a module, and USEing the
> module in the calling code. There is nothing at all wrong with doing this,
> in fact I reccommend it.
I've made some use of modules, but I've run into problems with the source
code for the module needing to be in the same directory as the source code
for the program I'm writing. I got so accustomed to bundling the object
files into a library and simply linking with the library. Is there a
similar way to bundle mod files into a single file that the compiler can
use?
Phillip Helbig---undress to reply
> I've made some use of modules, but I've run into problems with the source
> code for the module needing to be in the same directory as the source code
> for the program I'm writing. I got so accustomed to bundling the object
> files into a library and simply linking with the library. Is there a
> similar way to bundle mod files into a single file that the compiler can
> use?
It depends on the compiler. Some allow you to specify a directory for
the module files.
Gary L. Scott
Ron Shepard
> Is there a
> similar way to bundle mod files into a single file that the compiler can
> use?
No, not that is portable, but most compilers have an option to
specify other directories to search for *.mod files.
$.02 -Ron Shepard