From: Erez Haba <erezh@XXXXXXXXXXXXX>
Date: January 19, 2008 12:21:41 PM CST
To: "mpi-21@mpi-forum.org" <mpi-21@XXXXXXXXXXXXX>
Cc: "mpi-21@cs.uiuc.edu" <mpi-21@XXXXXXXXXXX>
Subject: RE: [mpi-21] const C++ MPI handles (take 2)
Reply-To: mpi-21@XXXXXXXXXXXXX

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@XXXXXXXXXXXXX
On Behalf Of Jeff Squyres
Sent: Friday, January 18, 2008 5:49 PM
To: mpi-21@XXXXXXXXXXXXX
Cc: mpi-21@XXXXXXXXXXX
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@mpi-forum.org [mailto:owner-mpi-21@mpi-forum.org]
> On Behalf Of Jeff Squyres
> Sent: Friday, January 18, 2008 11:14 AM
> To: mpi-21@mpi-forum.org
> Cc: mpi-21@XXXXXXXXXXX
> 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