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