Re: gfortran and the family of fortran array types

Richard Maine wrote:
| relaxmike <michael.baudin@xxxxxxxxx> wrote:
|
|| The fortran 90 array is declared as :
||
|| real(kind=C_FLOAT), dimension(:,:), allocatable, target :: mat
||
|| To be manageable by the C routine, a conversion must be done so that
|| only the base_addr field is passed to the C routine.
|
| That is not so. Of course, prior to f2003, the standard didn't provide
| any way at all to call C (or have the above C_FLOAT constant), but that
| aside, there would be no problems at all with passing the above array to
| C. It does *NOT* require the use of C_LOC.
|
| You appear to be assuming that all arrays are inherently passed as dope
| vectors, which is not so. I suspect that the confusion partly arises
| from looking at argument passing conventions exactly backwards. To see
| how an array is passed to a particular subroutine, you do *NOT* start
| out by looking at the array in question. You start out by looking at the
| interface of the subroutine. That's what defines the expected passing
| mechanism.

But other than that, his post was pretty much spot on.

From a practical compiler implementation standpoint, interfacing F90 with C
(subtleties like CHARACTER aside) works pretty much as interfacing F90 with
F77. Neither C nor F77 know about assumed-shape, allocatable or pointer
arguments (and associated dope vector) -- all they "know" is an address of
the first element. In C it is expressed more explicitly with * operator,
while in F77 one uses an assumed-size (or explicit-shape) dummy.

Thus, (attempting to express Richard's point somewhat differently): a F90
compiler may (but need not) mantain a dope vector internally, as a bookkeeping
device; but whether it will pass it or not depends *only* on the called routine
interface/prototype. If it's a f90 assumed-shape/allocatable/pointer argument
(which, remind you, need an /explicit interface/), it will pass it (and
create one on the fly if necessary, such as in CALL FOO(A(1:8:2)) or
CALL Foo([12,8,2008,12,53]) ). Otherwise, it will "just" pass the address.

With F2003 C interop, C_LOC does that conversion explicitly and is
guaranteed to be portable. Before that, one would just pass the array
(assumed-size assumed by compiler), relying on both compilers to do
the right thing (they would most often do, but it wasn't guaranteed
by the Standard).

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

.

Relevant Pages

  • Re: arrays as arguments
    ... Makes me wonder what compiler it is that has such poor error ... to a routine that expects a pointer or assumed-shape array ... things that requires an explicit interface. ...
    (comp.lang.fortran)
  • Speed versus memory
    ... My initial impulse was to use vector processes everywhere. ... an absurd amount of memory. ... Such a routine only has two input arrays ... and one output array but goes through ten intermediate arrays all of ...
    (comp.lang.fortran)
  • Re: CVF compiler question, program giving inconsistent results
    ... Run time error checking for "Array and string bounds" is turned on. ... There is no Monte Carlo stuff in this code. ... routine in a support library that generates a "random" ... Right after the LOGICAL INITS declaration there is ...
    (comp.lang.fortran)
  • Re: Routine Interfering with Clipboard
    ... Otherwise use the temporary array, eg open one wb, assign the values ... file in created Inst2 that from its Open event starts a new routine called ... The macro therefore takes 25mins to run. ... instance of Excel and then open a second hidden instance to do all the ...
    (microsoft.public.excel.programming)
  • Re: Passing an array to a sub routine
    ... FileHandle, Array, Hash, Method, Regex}? ... The LoadDataFile routine works correctly, but the SaveDataFile ... > sub LoadDataFile ...
    (comp.lang.perl.misc)