On Jan 1, 2008, at 12:47 AM, Adam C Powell IV wrote:

On Mon, 2007-12-31 at 20:01 -0700, Brian Barrett wrote:


Yeah, this is a complicated example, mostly because HDF5 should
really be covering this problem for you.  I think your only option at
that point would be to use the #define to not include the C++ code.

The problem is that the MPI standard *requires* mpi.h to include both
the C and C++ interface declarations if you're using C++.  There's no
way for the preprocessor to determine whether there's a currently
active extern "C" block, so there's really not much we can do.  Best
hope would be to get the HDF5 guys to properly protect their code
from C++...

Okay. So in HDF5, since they call MPI from C, they're just using the C
interface, right?  So should they define OMPI_SKIP_MPICXX just in case
they're #included by C++ and using OpenMPI, or is there a more MPI
implementation-agnostic way to do it?


No, they should definitely not be disabling the C++bindings inside HDF5 -- that would be a situation worse than the current one. Consider the case where an application uses both HDF5 and the C++ MPI bindings. It includes hdf5.h before mpi.h. The hdf5.h includes mpi.h, without the C++ bindings. The application then includes mpi.h, wanting the C++ bindings. But the multiple inclusion protection in mpi.h means nothing happens, so no C++ bindings.

My comment about HDF5 was that it would be easiest if it protected its declarations with extern "C" when using C++. This is what most packages that might be used with C++ do, and it works pretty well. I'd actually be surprised if modern versions of HDF5 didn't already do that.

Now that it's not New Years eve, I thought of what's probably the easiest solution for you. Just include mpi.h (outside your extern "C" block) before hdf5.h. The multiple inclusion protection in mpi.h will mean that the preprocessor removes everything from the mpi.h that's included from hdf5.h. So the extern "C" around the hdf5.h shouldn't be too much of a problem.

Hope this helps,

Brian

--
  Brian Barrett
  Open MPI developer
  http://www.open-mpi.org/


Reply via email to