Re: Does the order of declarations matter?

robin wrote:

> I asked, because the OP used the old way, and is prone to error.
> Better to pick up n from the actual bound of dum, rather than
> passing it as a separate argument.

The old way is better unless there are compelling reasons
to do otherwise. The main reason is for clarity; another is

For example, the declarations
integer, intent(in):: k,m,n
real,intent(in):: a(k,m), b(m,n)
real,intent(out):: c(k,n)

make clear the programmer's expectations regarding the sizes
of the arrays; it's also obvious from the declarations that
is well-defined. It's much harder to infer the programmer's intent
from declarations of the form
real,intent(in):: a(:,:), b(:,:)
and so on; one must search through the rest of the code to
find out, and the constructs are clumsy:
if(size(a,1) == size(c,1) .and. size(a,2)==size(b,1) .and. &
size(b,2) == size(c,2)) then

Most compilers generate faster code from the first set of
declarations than the second (assuming that the actual
arrays are contiguous in memory) because the compiler
does not need to deal with a dope vector to do the requisite
addressing. SGI (among others) states that four times as
many instructions must be generated to index a (:,:) array than
an (m,n) array.

Explicit shape (the first set above) has the disadvantage that
the programmer must manage extra dummy arguments, which
can be problematic. Assumed shape (second set) sometimes
is preferable if one wants to write a generic subroutine to perform
some action on an array without the overhead of passing dimensions.
Either way, however, the programmer must get the correspondence
between actual and dummy arrays correct for the code to work,
and explicit-shape declarations are quite helpful for this purpose.

There was a discussion awhile back about the possibility of a future
INFERRED attribute, which would provide a run-time check
on the consistency of explicit-shape arguments. I think it would
be a nice facility that would improve the robustness of many programs.