The issue is really one of whether the C++ (or Fortran) interfaces call the C MPI interface or not. There are both reasons to do so and reasons not. The reasons for is that a developer can write a profiling library that intercepts the C calls; on an implementation that routes everything through C, this simplifies their effort (at some cost in precision of call). In this case, the user should have make use of the PMPI::Init interface. Bill On Mar 5, 2012, at 4:27 AM, Bronis R. de Supinski wrote:

Um, it is standard practice when using the profiling interface to redefine MPI_* functions. I think this question is one for the C and C++ standards, not MPI...

On Sun, 4 Mar 2012, Jeff Hammond wrote:

...

What was ambiguous to me - looking at 2.6.3-4 - was if using MPI_ was still a protected namespace in C++. The standard really only says explicitly that it is so in C. It is only with an indirect argument that mpi.h can define both C and C++ bindings that I can see C++ code not being able to define MPI_ functions.

Note that MyMPI_ was ~exactly~ how I fixed the user's code :-)

Jeff

On Sun, Mar 4, 2012 at 9:39 PM, Fab Tillier <[email protected]> wrote:

...

I don't think defining one's own mpi.h is an issue from a compliance perspective. However, overloading MPI_Init definitely is - the standard reserves the MPI_ namespace, so if it isn't in the standard, it's not standard compliant. Now, if they named it MyMPI_Init, it'd be fine.

-Fab

Jeff Hammond wrote on Sun, 4 Mar 2012 at 18:22:40

...

I have a user who insists it is MPI-compliant to do the following:

user file mpi.h, which is included in the application with #include "mpi.h": ================================== #include <mpi.h>

<snip>

void MPI_Init(int argc, char* argv[], int& my_rank, int& mpi_size, int& Master) { MPI::Init(argc, argv); my_rank = MPI::COMM_WORLD.Get_rank(); mpi_size = MPI::COMM_WORLD.Get_size(); Master = 0;

std::cout << "Hello World! I am " << my_rank << " of " << mpi_size << std::endl; }

void MPI_finalize() {MPI::Finalize();}

==================================

I believe that it is a terrible practice, if not a violation of the MPI standard to: (1) define one's own mpi.h, since this may confuse the preprocessor (or are there precedence rules in the ANSI C standard?) as to which to include first (especially if CC=mpicc or CXX=mpicxx), and (2) overload MPI_Init, even if one is using C++ and relying upon C++ name-mangling to avoid a symbol conflict.

The user believes that the inability to overload MPI_Init in C++ means that MPI is not compliant with the C++ standard.

Thanks,

Jeff

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/old/index.php/User:Jhammond https://wiki-old.alcf.anl.gov/index.php/User:Jhammond

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

---

mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign