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

[Erez Haba]

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