MIXED is a directory of C programs which contains some simple examples of mixed language program. In particular, this directory considers situations in which the main program is written in C.
Because higher level languages end up as machine code, there is some reason to assume that you can write parts of a program in two different languages; what is not standard is the protocol for dealing with the differences in languages.
For instance, C does not explicitly support complex data types, and the C mathematical library does not include the corresponding arithmetic support. It's easy enough to make something that looks like a complex number in C:
typedef struct ( float r, i } complex;
complex alpha;
alpha.r = 1.0;
alpha.i = 2.0;
but you still can't compute directly with complex numbers in C.
Another commonly noticed difference between C and FORTRAN is that C passes scalar parameters by value, whereas FORTRAN passes all variables by address. Thus, if a C routine wants to call a FORTRAN subroutine, it must put the reference symbol & in front of each scalar variable to ensure that FORTRAN receives what it's expecting.
On the other hand, if a FORTRAN routine needs to pass a scalar parameter to a C routine, there is no standard way to ensure that a value is passed rather than an address. The only possibility is that some vendors have included the ability to compute the address of a variable in FORTRAN, sometimes by using the same & operator available in C, but this is by no means a universal option. If the C routine can be rewritten, then another option is to preface such scalar variables with the * operator in the routine declaration, indicating that these variables are being passed into the function by address rather than value. If the C routine cannot be rewritten, then the only other option is to try to use some of the fancier features added to FORTRAN90.
Yet another issue occurs because of things the compiler does to symbolic names. In order to avoid confusion between names the user defines and names the compiler wants to reserve, it is common in some cases to append an underscore to user-defined names. In particular, a FORTRAN compiler is likely to take the name of a common block, function, or subroutine, and first CAPITALIZE it, and then append an underscore. This is fine, as long as the compiler also does the same thing when it encounters a line of code that tries to access the same symbolic quantity.
The C compiler is likely to do no such thing. Thus, if the user has written a FORTRAN routine called "fred", it may not be possible for a C routine to reference "fred", but it may be possible for it to make the connection by asking for "FRED_"! Thus, if the C code can be adjusted, then the two languages may be able to work together by having the C code be careful about how it refers to FORTRAN symbolic names. On the other hand, the FORTRAN compiler often has a switch that allows the user to turn off the automatic capitalization and underscore-postfixation, which may accomplish the same goal.
For historical reasons, a C function that returns a float actually returns a value that is promoted to a double. This means that it is not possible to write a C routine that "looks like" a FORTRAN function of real type. If you do your best to write such a routine, it will actually behave as though it is a FORTRAN function of double precision type. This is not a problem if the data is being passed back out through the argument list, rather than through the name of the routine.
In some cases, a FORTRAN function with COMPLEX value is equivalent to a C function with an extra first argument pointing to the address of the return value:
complex function f ( x, y )
could be mimicked in C by
F_ ( temp, x, y )
struct ( float r, i ) *temp;
Similarly, a FORTRAN function which returns a CHARACTER value may be equivalent to a C function with two extra initial arguments giving the address and length of the return value:
character*14 function g ( x, y )
or
character ( len = 14 ) function g ( x, y )
could be mimicked in C by
G_ ( char result[], long *length, x, y )
Analogously, passing a character variable anywhere in a FORTRAN argument list may be equivalent to passing the pair of values consisting of the character string and its length.
Even if you get the two parts of your program to be compatible, you still have to worry about what happens when you load them, because both FORTRAN and C provide certain auxiliary I/O and math libraries. If things are going your way, you may be able to get away with using the FORTRAN command to load, but appending a switch to add the C mathematical library as well:
f90 my_main.o my_sub.o -lm
or, perhaps there is also a "C" library:
f90 my_main.o my_sub.o -lc -lm
If you are using C to load, you may need to include the appropriate FORTRAN libraries. (Warning: the names of these libraries are nowhere near as standard as the C math library. And the FORTRAN IO and math libraries may be distinct):
cc my_main.o my_sub.o -lfor -lm
C++ supports (on purpose!) a scheme in which the names chosen by a user for various functions are automatically mangled, because it is assumed likely that the same name could be used in different namespaces, so C++ avoids ambiguity by constructing unique internal names when compiling. Unfortunately, this makes it very difficult for programs written in other languages to interact with a C++ program. One feature that can help is the use of the statement
external "C" { (list of function declarations) }
in a C++ program in which name mangling is to be deactivated.
The list of function declarations can be either the names of
C routines to be called from this C++ routine, OR the names
of internal C++ routines that are to be called by an external
C routine.
The computer code and data files described and made available on this web page are distributed under the GNU LGPL license.
MIXED language programming examples are available in a C version and a C++ version and a FORTRAN90 version
C_CALLS_F77, C programs which illustrate a C program calling a FORTRAN77 subroutine.
C_CALLS_F90, C programs which illustrate a C program calling a FORTRAN90 subroutine.
C++_CALLS_F77, C++ programs which illustrate how a C++ main program can call a FORTRAN77 subroutine.
C++_CALLS_F90, C++ programs which illustrate how a C++ main program can call a FORTRAN90 subroutine.
F77_CALLS_C, FORTRAN77 programs which illustrate how a FORTRAN77 program can call a C function.
F77_CALLS_C++, FORTRAN77 programs which illustrate how a FORTRAN77 program can call a C++ function.
F90_CALLS_C FORTRAN90 programs which illustrate how a FORTRAN90 program can call a C function.
F90_CALLS_C++, FORTRAN90 examples which illustrate how a FORTRAN90 program can call a C++ function.
MATLAB_CALLS_C, MATLAB programs which illustrate how a MATLAB program can call a C function, using MATLAB's MEX facility.
EX1 shows how a C main program can call a FORTRAN90 subroutine. The C main program calls the FORTRAN90 routines by their exact names, without appending an underscore. It is assumed that the FORTRAN compiler will be called in such a way that no underscores will be added to the compiled names. Files you may copy include:
EX2 shows how a C main program can call a FORTRAN90 routine, passing data of various kinds back and forth. The C main program calls the FORTRAN90 routines appending an underscore to their names. This assumes that the FORTRAN compiler will, by default, add underscores to the compiled names. Files you may copy include:
EX1_CC_FORT uses the cc and fort compilers on example 1. Files you may copy include:
EX1_GCC_FORT uses the gcc and fort compilers on example 1. Files you may copy include:
EX2_CC_FORT uses the cc and fort compilers on example 2. Files you may copy include:
EX2_GCC_FORT uses the gcc and fort compilers on example 2. Files you may copy include:
You can go up one level to the C source codes.