Fortran functions may be called differently from C++ than from C.
However, C++ can always call pure C through extern "C" { }.
To include C functions that are C++ incompatible
we would write the following in out C++ code:
extern "C" {
where c_stuff.h contains the headers for the troublesome "pure" C functions.
See also the
C++ faq, section 29.2 .
#include "c_stuff.h"
};
Thus, the following is a method to call Fortran from C++: We write a header file, say dfzero.h, where we simply declare the Fortran function dfzero as C function. We then #include dfzero.h inside the extern "C" { } brackets. Then simply compile your C++ file; don't forget to link to the Slatec library.
For example, below, we make a C header for the Slatec function sgeev (which
finds matrix eigenvectors), and put it directly within the
extern "C" { } brackets.
extern "C"
{
void sgeev(float[][maxdim],int*,int*, complex[],
complex[][maxdim],int*, float[], int*, int*);
};
Now you should be able to use the Slatec function sgeev in your C++ code.
Just a note: Many compilers may even let you #include uncompiled .c-files inside the extern "C".
As said before, when using several Slatec functions in your program, the great number of function arguments and the not so straighforward usage of the Slatec routines may bother you, the programmer, or someone trying to read and understand your code. C++ can be a good and easy way to package these routines.
We demonstrate Slatec calls from C++ in the example below. The set of files
below is a program that computes the energy eigenstates of a system with a
harmonic oscillator potential confined within an infinite well.
When the files below are compiled and executed, the program will ask
how wide you want to make the confining infinite well, in
normalized coordinates s=x/a,
where a is the classical turning point of the
groundstate energy eigenfunction of the SHO.
Entering some number b will put confining walls
at s=b and s=-b.
Program will also ask for the dimension of the spectral differentiation
matrix should be; answer some integer like 20. The first three eigenfunctions' datapoints
[xi,Psi(xi)] are saved in the text files
0.dat, 1.dat,2.dat when the program quits.
The program also makes a file es.dat, of the ground state
energies of the
system, as a function of the paramater b (well position).
spectral.cc.txt
dgemm.cc.txt
sgeev.cc.txt
fcomplexdef.h.txt
Some things to note when playing with the program:
The wavefunctions look pretty much like something we would expect. Not terribly stunning.
For large b: the first few eigenfunctions will basically look like a SHO, since that wall is placed very far beyond the classical turning point.
For b quite a bit less than Pi/2, the SHO potential will have negligible effect, or slightly perturbing effect, on the wavefunction. Wavefunction looks like a simple sine standing wave of the infinite well.
For b~Pi/2 the ground state energies of the SHO and infinite well are comparable.
For b=1 the wall is placed at the classical turning point of the
groundstate SHO. However, the energy of the infinite well predominates, as this
is case falls in the second category. Program computes the groundstate energy
for this case to be 1.298 (in terms of hbar omega). Energy for the ordinary
infinite well would be 1/8 Pi^2~1.234 hbar omega,
for a well given by b=s=1,
where s is the scaled unitless position coordinate;
hence the extra energy due to the perturbation of the HO potential is only
about 5 percent.
For approximately b=1.876016 the wall is placed at the classical turning point of the second (computed eigenvalue) energy of the hybrid inf.well-HO system. The following postscript file shows the first three eigenfunctions that the program computed. File: b1876.ps. Note that groundstate here is SHO-like, while the third state already looks infinite-well-like.