Passing info about an array

[WSinc]

I treied using both DIM and LEN to pass information about an array I input

to a subroutine. For example:

REAL  A(-23:35)

CALL SUB1(A)

Do I explicititly have to tell it how big the array is in a separate

item in the call sequence? In this case, A has 59 elements,

(35-(-23)+1) so would I have to say:

REAL A(-23:35)

CALL SUB1(59,A)

SUBROUTINE SUB1(NA,A)

REAL  A(1:NA)

INTEGER NA

---------------------------------------------------------------------------------------

I thought that the newest Fotran has a way to provide all that info

just by passing the array name.

Maybe there is an article about this somewhere?

I could not find it.

Does the subroutine have a way of knowing the upper and limits of

the array for boundary checking, to prevent storing information

outside its bounds? Otherwise you could get some nasty hard to find bugs.

[WSinc]

Yes, that seems like the "safest" way to do it - -

Thanks ! ! !

[IanH]

A note of caution though - being able to call a procedure without it having an interface shouldn't be regarded as a feature - there are clear benefits in argument consistency checking that should not be ignored (with module and internal procedures there are further benefits in terms of the interface being provided with minimal programmer effort).  With assumed shape arrays you can write the equivalent:

[fortran]  REAL A(-25:25), B(-3:19)
  CALL SUB90(A(-7:13), -7)
  CALL SUB90(A, LBOUND(A))
  CALL SUB90(B, LBOUND(B))
CONTAINS
  SUBROUTINE SUB90(x, i)
    INTEGER :: i
    REAL :: x(i:)
    WRITE (*,*) 'SUB90: SIZE=',SIZE(x), LBOUND(x), UBOUND(x)
  END SUBROUTINE SUB90
END[/fortran]

Most compilers with array subscript debugging options would catch any invalid array subscripts both inside SUB90 and in the references to SUB90.  If you use the external subprogram/explicit shape array approach then you are far less likely to have problems at the call site caught.

[John_Campbell]

Bill,

You might also want to try the call example:

     CALL SUB77 (A(-7:13), lbound(A(-7:13)), ubound(A(-7:13)))

This did not give the result I was hopeing for, returning a lower bound of 1 and an upper bound of 21 !

While CONTAINS has some benefits, I had a recent problem with mixing compiler debug and optimisation levels for different routines (files).
I compiled the module and some routines I wanted to check with checking options, but needed to compile the key data manipulation routines with high optimisation. To easily achieve this I seperated these utility routines into a seperate file, requiring them to not be contained.
Perhaps CONTAINS is good for a code that is fully written, while I spend most of my time using the compiler to develop new code.

John

[IanH]

The simple solution to a requirement for separate compilation is to put the code in a module.  If you can chop and internal procedure out as an external procedure then I cannot think of anything that stops you making it a module procedure (perhaps some dastardly dependency loop).  I use an internal procedure here simply for the sake of the example - bar single program unit codes (i.e. main program, nothing else) I generally do not use internal procedures because of the inability to control inheritance of things from the host.

[WSinc]

Boy - this is getting a LOT more complicated than I first thought ! ! !

But I will try these different approaches. Heck, maybe even a COMMON block.

But that's ancient history, right ?  :<)

Pardon me, I need to go and feed my horse.......Giddyap !