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

I looked up this issue and did not find a C++ *standard* that spans  
that many platforms and compilers.

The ISO C++ 98 standard itself does have libraries, but they provide  
the headers which are less ambiguous. (including various const values  
(like INT_MAX)) (think ABI :))

I agree that we'll need to enable the recommendation in the standard  
interface. We'll need to agree that the semantic of changing the  
underlying MPI handle is not changing the object (and thus can define  
the method as const).

I don't think you'll need an overloaded function for the Set_*  
functions; const methods are good for non const objects.

Thanks,
.Erez

-----Original Message-----
From: owner-mpi-21@XXXXXXXXXXXXX
On Behalf Of Jeff Squyres
Sent: Thursday, January 17, 2008 10:26 AM
To: mpi-21@XXXXXXXXXXXXX
Subject: Re: [mpi-21] const MPI C++ handles

On Jan 17, 2008, at 12:30 PM, Erez Haba wrote:

> 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.

That's a good point -- what is common practice in the C++ community?
Do they specify const for global variables?  Or do they refrain from
specifying, as you suggested?  I honestly don't know.

However, even if we don't specify it in the standard and only
"recommend" that the handles are const, we have to allow for it in the
standard's interface.  So I think that means making both const and non-
const versions of the Set_* methods where appropriate (e.g., the
Set_attribute(), Set_name(), and Set_errhandler methods on classes
that allow such operations on predefined handles).

> 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@mpi-forum.org [mailto:owner-mpi-21@mpi-forum.org]
> On Behalf Of Jeff Squyres
> Sent: Thursday, January 17, 2008 8:19 AM
> To: mpi-21@mpi-forum.org
> 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
>


--
Jeff Squyres
Cisco Systems