Re: Does the order of declarations matter?

ejko123@xxxxxxxxx wrote in message <1138334650.498277.110620@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>...
>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
> c=matmul(a,b)

matmul? nobody said anything about matmul in this problem.
As I said before, this form is error prone, and
in any case, the programmer still has to perform any checks
that might be needed on the bounds of the arrays.

>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,

find out what?
Hopefully, the purpose of the subroutine will be spelled out
in a description.

> 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
> c=matmul(a,b)
>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.