Re: Chapter 7

(no name) (Andrew.Lumsdaine@nd.edu)
Thu, 23 May 1996 14:20:12 -0500 (EST)

In our last exciting episode James Cownie wrote:

> No problem...

> 1) The tacky way, (which is guaranteed to work).

> /* mpi++.h */
> #define MPI_Comm __C_MPI_Comm
> ...

> #include "mpi.h"
> #undef MPI_Comm
> ...

> 2) The clean way.
> (Assuming that your C++ compiler has namespace and that
> the way I read the standard is what is intended. None of the
> three C++ compilers I have will eat this, though YMMV).

> /* mpi++.h */

> namespace __MPI_impl
> {
> #include "mpi.h"
> }

Interoperability with C++ and C MPI bindings was not really the
problem we were raising -- both solutions 1 and 2 had occurred to us
for these particular problems. The more problematic issue is this.
Suppose I am writing a C++ program and I want to use a library (say,
Petsc) that uses the C bindings. If the library function expects a C
handle as an argument, there is a problem. For instance (this is
completely fictitious petsc code by the way), suppose a petsc call is
prototyped in "petsc.h" as

#include "mpi.h"
...
extern Petsc_call(MPI_Comm, Vector v1, Vector v2);

and the function is called in C++ code like this

#include "petsc.h"

Petsc_call(MPI_COMM_WORLD.C_handle(), vec_1, vec_2);

Now, for this to work, we have to make the user wrap up "petsc.h" with
either one of the mechanisms you mentioned. I think this might be our
only choice but I can't help but feel uneasy about it. If we are
wrapping up mpi.h it's one thing because we have control over what
goes in there. Requiring users to do it seems dangerous -- not
because it wouldn't work but because I can see people screwing things
up.

Sincerely,
Andrew Lumsdaine