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

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)
>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: Does the order of declarations matter?
    ... For example, the declarations ... arrays are contiguous in memory) because the compiler ... Either way, however, the programmer must get the correspondence ... and explicit-shape declarations are quite helpful for this purpose. ...
    (comp.lang.fortran)
  • 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: Integration of the right kind is finally upon us.
    ... He claimed that case was significant, and that starting arrays ... introducing errors (where varname, Varname, and ... programmer [tools _could_ prohibit the same case ... And, yes, in the Algols ...
    (comp.arch)
  • 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)