(j3.2006) TKR for C Interop
Thu Mar 1 12:44:31 EST 2007
On Thursday 01 March 2007 08:16, Bill Long wrote:
> If you want a universal library, you have to block inlining of these
> procedures.? Similarly, the include file used by the C function will be
> vendor supplied.?
I said earlier:
On Wednesday 28 February 2007 17:05, Aleksandar Donev wrote:
> If the C struct is fully specified (no opaque components),
> and the handles for the Fortran descriptors are pointers (void *), I think
> we have achieved that goal. Essentially the whole TR header file will be
> specified from Fortran, and the vendor will only provide the library that
> implements the specified API. For efficiency, we may want to allow a vendor
> to replace the header file with something that makes the routines macros,
> for example.
1) There is a "default" header file that is fully specified by the standard.
That is, even the values of constants such as "invalid rank" are specified by
us, not left as named constants.
2) The vendor is free to replace the include file with its own for efficiency
etc. But it is also required to support the default one.
I am not saying this should be a requirement. It is lower on the list of
priorities. But, if possible, I see it as a good thing. In the C world I
don't see much of it in the standards themselves, but behind the scenes I see
ABIs appear and implementations following them even though they are not
required by the standard. For example, on my system (Linux x86_64), there are
several GLUT (from OpenGL) libraries but they all try to use the same values
for predefined constants (say GL_ENABLE) so that there is binary
compatibility and one can switch (shared) libraries without recompiling
applications. It works nicely.
More information about the J3