How to re-engineer Fortran and C++ mixed-language library from common blocks - global struct aliasing?

Question

I have a program that consists of mostly Fortran 77 with a C++ wrapper that reads and writes to a database. The two parts of the application share data by uses a feature that if you use a global C/C++ struct named like a Fortran common block. I'm pretty sure this aliasing approach to C++/Fortran integration 1) works for many compiler suites, 2) is *not8 standard. I try to maintain my code so that it uses standard components as much as I can. Also, this integration has proven to be brittle.

In utd.h:

/*************************************************************
 *  This struct must follow the common block points.
 *  See the Fortran include file points.i
 *************************************************************/
typedef struct ALIGN points
{
    double  point[3][MAX_PTS];
    double  edge[3][MAX_PTS];
    double  edgenorm[3][MAX_PTS];
    double  edgerho[MAX_PTS];
    int     nfacets[MAX_PTS];
    double  facet1[3][MAX_PTS];
    double  facet2[3][MAX_PTS];
    double  gaussk[MAX_PTS];
    int     sbstin[MAX_PTS];
    int     coatin[MAX_PTS];
    int     sbstout[MAX_PTS];
    int     coatout[MAX_PTS];
    int     ncorners[MAX_PTS];
    double  cnrpoint[3][MAX_CNRS][MAX_PTS];
    int     ncnredgs[MAX_CNRS][MAX_PTS];
    double  cnredge[3][MAX_CNREDS][MAX_CNRS][MAX_PTS];
    int     cnrsbst[MAX_CNREDS][MAX_CNRS][MAX_PTS];
    int     cnrcoat[MAX_CNREDS][MAX_CNRS][MAX_PTS];
    int     npoints;
} POINTS;

extern POINTS  points_;

In utd.cpp:

POINTS  points_;

In points.i:

  !  maxpnt  -  maximum number of points in a path.
  integer  maxpnt
  parameter ( maxpnt = 1000 )

  integer npoints, nfacets(maxpnt)
  integer ncorners(maxpnt), ncnredgs(maxpnt,maxcorners)
  integer sbstin(maxpnt), coatin(maxpnt)
  integer sbstout(maxpnt), coatout(maxpnt)
  double precision point(maxpnt,3)
  double precision edge(maxpnt,3), edgenorm(maxpnt,3)
  double precision edgerho(maxpnt)
  double precision facet1(maxpnt,3), facet2(maxpnt,3)
  double precision gaussk(maxpnt), cnrpoint(maxpnt,maxcorners,3)
  double precision cnredge(maxpnt,maxcorners,maxcnredges,3)
  integer cnrsbst(maxpnt,maxcorners,maxcnredges)
  integer cnrcoat(maxpnt,maxcorners,maxcnredges)

  common /points/ point, edge, edgenorm, edgerho,
 *                nfacets, facet1, facet2, gaussk,
 *                sbstin, coatin, sbstout, coatout,
 *                ncorners, cnrpoint, ncnredgs,
 *                cnredge, cnrsbst, cnrcoat,
 *                npoints

Is there a better way? I might like to convert the common blocks to modules. Then I'm sure this business of aliasing a common block with a global struct is out the window. How you you construct a Fortran module from C++? How do you read data from such a module?

What is your advice about C++/Fortran integration?

Answer 1

The ISO C Binding of Fortran 2003 makes interoperability of C and Fortran part of the Fortran language standard, and therefore compiler and platform portable. If you only use features of C, most likely it will work in C++, though perhaps that is not absolutely guaranteed. You can mix Fortran 2003 and FORTRAN 77, either within a source file or by mixing routines written in the two versions of the languages. The ISO C Binding supports structures and module variables as global variables, so it can accomplish your goals. Both of these are shown in the Mixed Language Programming Chapter of the gfortran manual. (The ISO C Binding is not specific to gfortran, I'm citing that as a good document.)

Common blocks are also supported, but I agree with you, best avoided ... common blocks add on FORTRAN storage sequence and layout, which is unnecessary. I don't see any way around manually maintaining the C and Fortran "structures" to have equivalent declarations. If that is the reason for the brittleness you will just have to be careful (baring writing a program to write both from common instructions). One approach that would make it a little easier would be not to put the variables into a structure ... then getting a new variable wrong is less likely to effect the older variables and that might make noticing or debugging a mistake easier.