[mpi-21] const C++ MPI handles (take 2)

[Jeff Squyres]

Because I have a mail proposal pending to restore the "const" that was  
[erroneously, IMHO] removed in ballot 2.  :-D

On Jan 19, 2008, at 5:59 PM, Erez Haba wrote:

> If the 'const' was removed in ballot 2 whey do you want to leave the  
> text that refers to it?
>
> -----Original Message-----
> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]]  
> On Behalf Of Jeff Squyres
> Sent: Saturday, January 19, 2008 11:17 AM
> To: mpi-21_at_[hidden]
> Cc: mpi-21_at_[hidden]
> Subject: Re: [mpi-21] const C++ MPI handles (take 2)
>
> Well, we pretty much have so far.  :-)
>
> The const was removed in ballot 2, but I wonder how many people
> actually noticed (I didn't, until a few days ago).
>
>
>
> On Jan 19, 2008, at 1:21 PM, Erez Haba wrote:
>
>> I agree, const is the better way to implement. The question is: do
>> you want to *force* the optimized implementation?
>>
>> -----Original Message-----
>> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]]
>> On Behalf Of Jeff Squyres
>> Sent: Friday, January 18, 2008 5:49 PM
>> To: mpi-21_at_[hidden]
>> Cc: mpi-21_at_[hidden]
>> Subject: Re: [mpi-21] const C++ MPI handles (take 2)
>>
>> Yes, that's the way the original C++ bindings were implemented.  But
>> it's not required or necessary to do that; that C errhandler could
>> easily be cached somewhere else.
>>
>> More specifically, isn't it better to have a const object to allow  
>> for
>> compiler optimizations?  (I'm not a compiler guru, but I thought the
>> point of why we originally made the C++ handles be const was on the
>> argument for potential compiler optimizations)
>>
>>
>> On Jan 18, 2008, at 8:35 PM, Erez Haba wrote:
>>
>>> For example an implementation might choose to cache the error
>>> handler for MPI::COMM_WORD (in the MPI::Comm object) and call it
>>> itself on error so it can pass in the right object to the error
>>> handler.
>>> Thus requiring MPI::COMM_WORLD not to be const.
>>>
>>>
>>> -----Original Message-----
>>> From: owner-mpi-21_at_[hidden] [mailto:owner-mpi-21_at_[hidden]]
>>> On Behalf Of Jeff Squyres
>>> Sent: Friday, January 18, 2008 11:14 AM
>>> To: mpi-21_at_[hidden]
>>> Cc: mpi-21_at_[hidden]
>>> Subject: [mpi-21] const C++ MPI handles (take 2)
>>>
>>> On Jan 18, 2008, at 2:02 PM, Erez Haba wrote:
>>>
>>>> Okay; about one issue at a time.
>>>
>>> Changing mail subject to reflect the discussion...
>>>
>>>> *For this sentence* it does not matter what's a common usage for C 
>>>> ++
>>>> global variables. Some MPI implementations would need to have non-
>>>> const qualified global objects.
>>>
>>> Why?  As I understand it, most (all?) MPI C++ implementations
>>> currently only require some objects to be non-const because of the
>>> standard-related issue that was already raised (Set_attr(),
>>> Set_name(), Set_errhandler() methods not having const variants).  Is
>>> there a reason that an implementation would *need* MPI handles to be
>>> non-const?
>>>
>>> Per my prior mail, I believe that the standard should specify that
>>> some of the methods on these classes should have const and non-const
>>> variants, and then it should be fine to require that the predefined
>>> handles be const.
>>>
>>> So the question is still open: what's common practice in the C++
>>> community regarding const/non-const global variable specification?
>>> This question will be moot if you can demonstrate that an
>>> implementation would need non-const C++ MPI predefined handles.
>>>
>>> --
>>> Jeff Squyres
>>> Cisco Systems
>>>
>>
>>
>> --
>> Jeff Squyres
>> Cisco Systems
>>
>
>
> --
> Jeff Squyres
> Cisco Systems
>


-- 
Jeff Squyres
Cisco Systems