(j3.2006) Interesting F2003-ism

[Bill Long]

Aleksandar Donev wrote:

>Bill Long wrote:
>  
>
>>The interop TR is for assumed-shape, allocatable, pointer, and optional 
>>dummy arguments.  The capability discussed above has nothing to do with 
>>any of those attributes.
>>    
>>
>In your short-sighted view of Interop, in which you think most 
>interoperable routines are written in C and you want C users to call 
>fast numerical Fortran routines, maybe it has nothing to do. 
>
I use C interop both directions, as was intended.  Calling libc routines 
directly from Fortran to access OS facilities is quite useful.


>But in the 
>real world, in which Fortran scientific programemrs also need to rely on 
>using lots of libraries written by their colleagues in C/C++, it is 
>essential. 
>

The new interop features are for dummy arguments that are assumed-shape, 
allocatable, pointer, or optional.  At the beginning, only Fortran 
callees have arguments like these, so initially in the actual real 
world, all the focus will be on C calling Fortran.  None of the "lots of 
libraries" you mention are set up to deal with this.  If the goal is 
just to write conversion wrappers to access the C routines, those 
wrappers can be written if Fortran just as easily.  It would be 
encouraging if some C libraries were written directly with the intent of 
supporting non-trivial arrays and use the TR's model for arrays, but I 
see that as a bit down the road.


>No one in C will write two different procedures, one to 
>handle an assumed shape array of rank-1, and another of rank-2, up to 
>15. 
>

Well, all but one of these procedures would be just a single line, but I 
agree that even that would irk most C programmers.

>It is a complete and useless waste of time for everyone and is what 
>gives Fortran its bad name...
>

No one in Fortran will want to write 15 interface bodies either.   If 
you want rank-independent argument matching, then changing the bind(c) 
rules is absolutely the wrong solution.  Some (most?) vendors already 
have a directive-based solution for this.  We supply an IGNORE_TKR 
directive that can be used to tell the compiler to ignore Type, Kind, or 
Rank (or any combination) when doing argument matching for a dummy 
argument. Use that in your interface and you need only one body.   (Note 
to Andy: If you want to do something useful in g95, implement this 
directive instead of messing with the bind(c) rules.  It looks like you 
have access to a Sun compiler; I assume they have a similar directive - 
see their docs for details.)  In a later version of Fortran it would be 
conceptually trivial to convert such a directive to attribute syntax.

Just curious, since I don't that often see C libraries used in 
scientific codes, what types of libraries are you talking about that 
someone might in the future write to handle these new types of 
arguments?   Most of the rank-independent arguments I see in C libraries 
are typeless buffers in routines used to just move data from one place 
to another. Given that Fortran has intrinsic assignment for arrays, 
libraries like these seem irrelevant to a Fortran programmer.

Cheers,
Bill

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

            

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3.scs.gmu.edu/pipermail/j3/attachments/20070223/b2b91a1a/attachment-0001.html