From: Jeff Squyres <jsquyres@XXXXXXXXX>
Date: January 18, 2008 12:57:39 PM CST
To: mpi-21@XXXXXXXXXXXXX
Cc: "mpi-21@cs.uiuc.edu" <mpi-21@XXXXXXXXXXX>
Subject: Re: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++  
handles
Reply-To: mpi-21@XXXXXXXXXXXXX

On Jan 18, 2008, at 1:53 PM, Erez Haba wrote:

> Aren't we also removing the const :)
> The text would still be incorrect; in some implementations the  
> MPI::COMM_WORLD is not const qualified.
>
> I suggest removing this sentence. (In C++....)

One issue at a time: this proposal is to remove "static" because it  
is clearly wrong.  The "const" issue is different, and [much] more  
complicated.

I am working on another proposal about the "const" issue in this  
sentence -- I still haven't heard back from you (or others) about  
what is common usage for C++ global variables (whether it is common  
to not specify whether they should be const or not).


> -----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 10:29 AM
> To: mpi-21@XXXXXXXXXXXXXX mpi-
> Subject: [mpi-21] Ballot 4 proposal: "static" predefined MPI C++  
> handles
>
> This mail is a proposal for MPI 2.1, ballot 4.
>
> NOTE: This mail is a slight re-formatting of http://www.mpi- 
> forum.org/mail_archive/mpi-21/2008/01/msg00119.html
>  to be in ballot proposal format.
>
> In MPI 2.0, page 9, lines 17-18 state:
>
> "MPI provides certain predefined opaque objects and predefined, static
> handles to these objects.  The user must not free such objects.  In C+
> +, this is enforced by declaring the handles to these predefined
> objects to be {\tt static const}."
>
> The "static" in the last sentence should be deleted.
>
> Rationale:
>
> When using namespaces, all the MPI symbols are in the namespace and
> objects do not need to be static in a singleton object for the MPI
> class.
>
> Specifically: they are static *only* if you are using the singleton
> object for the MPI class.  The context for the statement is talking
> about the constant quality; the "static" is superfluous -- describing
> whether "static" is necessary or not would be too much for this  
> section.
>
> --
> Jeff Squyres
> Cisco Systems
>


-- 
Jeff Squyres
Cisco Systems