Cisco Blogs

The MPI C++ Bindings

October 31, 2011 - 4 Comments

What a strange position I find myself in: the C++ bindings have become somewhat of a divisive issue in the MPI Forum.  There are basically 3 groups in the Forum:

  1. Those who want to keep the C++ bindings deprecated.  Meaning: do not delete them, but do not add any C++ bindings for new MPI-3 functions.
  2. Those who want to un-deprecate the C++ bindings.  Meaning: add C++ bindings for all new MPI-3 functions.
  3. Those who want to delete the C++ bindings.  Meaning: kill.  Axe.  Demolish.  Remove.  Never speak of them again.

Let me explain.

Back in the 1994-1996 timeframe, Andrew Lumsdaine (my graduate advisor) and I created the MPI C++ bindings and successfully got them to be an official part of the MPI-2.0 standard.

Our original intent for the bindings was to make them more-or-less a 1:1 mapping to the C bindings, but with a few extra C++ language features.  The Forum explicitly rejected the approach of making a new C++ class library for the bindings because that would be creating new semantics that are not part of the MPI standard.  These are bindings, after all, not new functionality.

The idea was that giving a few extra language-specific features in the C++ bindings would be a good bootstrap into making more interesting C++ class libraries.

Unfortunately, that intent never really materialized in 3rd party software.  The easiest C++ bindings fail to describe is the Boost.mpi C++ class library: it was implemented on top of the MPI C bindings — not the C++ bindings!  There were several valid reasons for this, but the gist of them was that the MPI C++ bindings didn’t add any value; why add another layer of translation in the middle?

Fast forward to MPI-2.2 (circa 2009).

I introduced a proposal to deprecate the C++ bindings because the goal of making them useful to C++ developers pretty much didn’t happen.  Plus, we kept finding subtle bugs and other issues in various individual MPI function C++ bindings.  My rationale was: why continue to maintain them?  They’re buggy, we don’t have a huge amount of C++ expertise on the Forum anymore (I haven’t used C++ deeply since the 90’s), and barely anyone is using them.

After some controversy, the deprecation proposal passed.  As of MPI-2.2, the MPI C++ bindings are officially deprecated.  Not deleted, mind you, just deprecated.  Meaning: no further work will be done on the C++ bindings, and they might be removed someday.

Fast forward to MPI-3 (circa 2011).

There’s a(n at-least-somewhat-valid) rising concern in the Forum that it’s “weird” that new MPI-3 functions have C and Fortran bindings, but no C++ bindings.  Hence, if you’re using the C++ bindings to write an MPI application, you have to check to see whether there’s actually a binding for the function that you want to use.

This has led to the 3 groups of Forum members that I listed above.

On the one hand, there are a non-zero number of MPI codes out there using the C++ bindings.  The authors of these codes are actually quite vocal, and at least partially represent some of the biggest spenders in the HPC sector.

On the other hand, that non-zero number is very, very small compared to the total number of MPI codes out there.  The amount of Forum and implementor work to create and maintain these bindings is non-trivial.

So what’s the Right Thing to do here?  Got an opinion?


In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Interestingly, you mention Boost.MPI — perhaps building on it (contributing) could be the optimal option? So, something along the lines of #2, but explicitly regarding the Boost.MPI. It’s much more elegant than the C-style bindings (much less unnecessary clutter — by that I mean no repetitive boilerplate required as when you type something as easy as “MPI_Comm_rank(MPI_COMM_WORLD, &rank)” — yes, I know I’m using MPI, yes, I know MPI communicator is involved, yes, I want to get the rank — don’t need to be reminded twice, nor should I have to remind the compiler about it).
    The problem with Boost.MPI is that it doesn’t cover the MPI functionality completely, so perhaps contributing to it along the lines of #2 could be the way to go?

    • I’ve heard the same complaint about Boost.mpi (that it doesn’t cover all MPI functionality). I’ve also heard that it adds a bunch of dependencies.

      I don’t know whether Boost.mpi is actively being maintained or not. Regardless, it’s outside of the Forum’s scope to contribute to it. We can’t really include it in the MPI Standard, either — it’s different semantics than MPI defines (class libraries are great, and the Forum is all in favor of them — they’re just not suitable for being in the standard).

  2. I have to agree with Dursi. There has been warning about the state of the C++ bindings for a while.

    Many new students I work with use them thinking “C++ is that new thing better than C”, and create new code using the C++ bindings. While I know there is a lot of code out there that needs rewrites to use the C bindings, avoiding proliferation of the C++ bindings would be my vote and whack them all.

    It will only get worse in the future.

  3. If the c++ binding users want to use mpi3 functionality, then they’ll have to rewrite those parts of their code anyway, so I don’t see that it’s any huge burden to only have c bindings for the new routines. As to having to look up whether or not there are c++ bindings for a given routine – well, you shouldn’t be doing new development with deprecated interfaces. That’s pretty much the definition of deprecated.

    I’d say sticking with the status quo is the right thing in this situation. Leave it deprecated a bit longer. For my own purposes, I’d be just as happy with them being deleted, but I realize that my use cases are not the only use cases.