You're right, I was not checking 2.1 implementations. While 2.1 changelog item 2 does specifically mention those constants in all 3 languages, what about the other datatypes? (e.g., MPI_INT vs. MPI_INTEGER, etc.?) Per Alexander's comments: 1. Why would we artificially limit what types can be accessed from each language? "Probably never" is not really the same thing as "never." It may not be probable, but it is conceivable that a C++ program could call a Fortran computational library -- perhaps the C++ program is essentially the "driver" for a master/worker model, and the Fortran computational library is what does the back-end work. Exporting new handles for already-existing MPI objects to a specific implementation's language bindings is not a lot of work. 2. Regardless of which way we go, I think that the standard should be explicit about which constants are available in which language. Otherwise, codes have the danger of not being source code compatible if different implementations make different decisions. On Oct 24, 2008, at 9:43 AM, Hubert Ritzdorf wrote:

Hi,

as far as I remember it was cleared in the MPI 2.1 standardization process that "all" datatypes have to be defined in all 3 languages. Changelog item 2 requires this explicitly for MPI_LONG_LONG, MPI_LONG_LONG_INT, ... (But I think that some C++ datatypes are missing since there wasn't defined a name).

Possibly, Jeff is not referencing MPI 2.1 implementations.

Supalov, Alexander wrote:

...

Hi,

I think we should answer the following questions to decide whether and how to define the constants:

1. When would a C MPI program call Fortran MPI subprogram? Probably, never. 2. When would a Fortran MPI program call a C MPI subprogram? Sometimes. 3. When would a C++ MPI program call Fortran MPI program? Probably, never.

I don't agree. I know some programs of this kind.

Hubert

...

4. When would a Fortran MPI program call a C++ MPI program? Probably, never.

Here, "subprogram" means a part of program that relies on the MPI use or knowledge of MPI datatypes, etc. This may or may not be a direct call into the respective MPI library.

...

From this, what is needed is to define Fortran datatypes from mpif.h in C mpi.h. The rest does not seem relevant. Even the existing C++ definitions may just reflect C heritage.

Best regards.

Alexander

-----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, October 23, 2008 10:13 PM To: MPI 2.2 Subject: [Mpi-22] Should all constants/types be available in all languagebindings?

I notice that OMPI, MPICH2, Intel MPI, and HP MPI all do the following:

* define Fortran datatypes in mpi.h (e.g., MPI_INTEGER, MPI_DOUBLE) * define Fortran datatypes in the C++ MPI namespace (e.g., MPI::INTEGER, MPI::DOUBLE, etc.) * do *not* define C datatypes in mpif.h (e.g., MPI_INT, MPI_FLOAT, etc.)

Why? AFAICT, there is no rule about what constants have to appear in which language bindings. But doesn't that implicitly mean that all constants are supposed to appear in all language bindings?

(the argument for having MPI_DOUBLE available in C, for example, is that a C routine may be invoked to send or receive a message containing Fortran data. Similar arguments exist for why you'd want MPI datatypes from other languages available in your language)

This is also related to whether the type MPI::Fint should exist or not.

I just filed a ticket about these issues (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/56 ) and marked it as "feedback requested", meaning that I need feedback from the Forum before a proposal can be made.

What do people think?

_______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

-- Jeff Squyres Cisco Systems