From: Jeff Squyres <jsquyres@XXXXXXXXX>
Date: January 17, 2008 12:26:24 PM CST
To: mpi-21@XXXXXXXXXXXXX
Subject: Re: [mpi-21] const MPI C++ handles
Reply-To: mpi-21@XXXXXXXXXXXXX

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