From: Erez Haba <erezh@XXXXXXXXXXXXX>
Date: January 17, 2008 11:30:32 AM CST
To: "mpi-21@mpi-forum.org" <mpi-21@XXXXXXXXXXXXX>
Subject: RE: [mpi-21] const MPI C++ handles
Reply-To: mpi-21@XXXXXXXXXXXXX

Why should the standard care if these objects are const or not? Isn't it up to the implementation? Does it affect portability in any way?

For example MPI::COMM_WORD in one implementation might return a const object and in another might not. As long as the C++ class function signature is the same as defined by the standard (const wise); it should not matter.

I think that the standard should refrain from *defining* the const'ness of the global C++ objects, although it could *recommend* it.
However, when writing the code explicitly (like in MPI::BOTTOM case) the standard could mention the recommend way to define it (as a recommendation).

Thanks,
.Erez

-----Original Message-----
From: owner-mpi-21@XXXXXXXXXXXXX
Sent: Thursday, January 17, 2008 8:19 AM
To: mpi-21@XXXXXXXXXXXXX
Subject: [mpi-21] const MPI C++ handles

There is a blanket statement in MPI-2:2.5.1 (p23:16-18):

"MPI provides certain predefined opaque objects and predefined static
handles to these objects.  The user must not free such objects.  In C+
+ this is enforced by declaring the handles to these predefined
objects to be static ***const***."  (my emphasis)

This states that all pre-defined objects in the MPI C++ bindings are
const.  However, the already-voted-in ballot 2 for the MPI 2.0 errata
removed "const" from many of them (!).  This was because there are
several MPI functions that change predefined MPI objects (e.g.,
setting attributes, error handlers, and names on MPI objects).  Hence,
the *MPI handle* may be "const" (in a C++ sense), but the underlying
MPI object is not.

Hence, the ballot 2 removal of "const" from many of these handles
allows functions like <MPI_handle>.Set_errhandler() and
<MPI_handle>.Set_attribute() to work properly.

But -- is this right?

Specifically: is it acceptable practice to have an opaque C++ handle
be "const" when it has public methods that may change the underlying
entity that the C++ handle is pointing to?

If this is acceptable practice, then we should put "const" back on the
predefined MPI C++ handles and have const versions of
Set_errhandler(), Set_attribute(), and Set_name() to allow setting
errhandlers, attributes, and names on predefined MPI C++ handles.

If this is not acceptable practice, then we should remove the blanket
statement from MPI-2:2.5.1 (I've already raised the point that the
"static" should definitely be removed from that blanket statement).

Thoughts?

--
Jeff Squyres
Cisco Systems