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

What is I implement the C++ binding but I don't have an underlying C  
implementation? The C++ objects will hold all the relevant  
information and by defining MPI::COMM_WORLD const, you make it  
immutable.

Thanks,
.Erez

-----Original Message-----
From: owner-mpi-21@XXXXXXXXXXXXX
On Behalf Of Doug Gregor
Sent: Tuesday, January 22, 2008 5:38 AM
To: mpi-21@XXXXXXXXXXXXX
Subject: Re: [mpi-21] const MPI C++ handles


On Jan 17, 2008, at 1:26 PM, Jeff Squyres wrote:

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

Common practice in the C++ community is to use "const" for any global
variables that cannot be modified by the user.  With handles, there
are really two levels of "const"ness one could consider: whether the
handle itself can be changed (to point to some different object) and
whether the object that the handle refers to can be changed. In our
case, we're interested in making the handles themselves const (so
users can't reassign MPI::COMM_WORLD), but we always allow users to
modify the object the handle points to (e.g., adding attributes to
MPI::COMM_WORLD). That implies that the handles themselves should be
"const".

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

Please do not just "recommend" that certain handles be const; either
specify them to be const, or specify them to be non-const. Constness
changes the overloading behavior of functions, so leaving this kind of
thing as a recommendation invites very, very strange portability
problems across implementations.

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


As noted later, one only needs the "const" version of these methods.

         - Doug