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
performance.

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

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.

--Eric

.



Relevant Pages

  • Re: A VB.NET Critique
    ... the declarations like so: ... in .NET are actually *reference* types its just that *some* of those ... from a language design point of view and is of more relevance to those ... > (such as arrays and strings) just eludes me somewhat; ...
    (comp.programming)
  • Re: The linf project (2)
    ... character will be declared exactly as in fortran. ...   integer, string:: b ... Should regularity be imposed or only to be preferred in declarations? ... We also need to be able to declare arrays of strings. ...
    (comp.lang.fortran)
  • Re: question about negative indices in fortran 77
    ... > declared arrays together somehow. ... > subroutine statement up to the first executable statement ... in the common block they're declared like ... order to sanitize the program I should change the declarations in the ...
    (comp.lang.fortran)
  • Re: Does the order of declarations matter?
    ... >> I asked, because the OP used the old way, and is prone to error. ... >For example, the declarations ... the programmer still has to perform any checks ... that might be needed on the bounds of the arrays. ...
    (comp.lang.fortran)
  • Re: Sun f90 bad optimization for assumed-shape array
    ... assumed-shape arrays is that explicit-shape arrays are known to be ... referring to the Sun f90 compiler and how it implemented explicit-shape arrays dummy args. ...
    (comp.lang.fortran)