[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mpi-21] Fix MPI-2 C++ "static const" statement
- To: mpi-21@xxxxxxxxxxxxx
- Subject: [mpi-21] Fix MPI-2 C++ "static const" statement
- From: "Jeff Squyres" <jsquyres@xxxxxxxxx>
- Date: Tue, 15 Jan 2008 13:38:03 -0600
- Delivered-to: mpifrm-mpi-21-outgoing@mailbouncer.mcs.anl.gov
- Delivered-to: mpifrm-mpi-21@mailbouncer.mcs.anl.gov
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=m30oH43NkLS5H1/7Em+8SExiPQWeNEPN5Bwgy28Arps=; b=GG/r2xD5kCEYvP271aUX4TUMIN/APNAxv13/2FtboHK1DMN0z9clvrTpWt1tGEHxSHcecFTGET52UHACQGiwAX3TEBVd69LhW1ABlm2p+puIRQn5Q/HdkA9M0sPGaxjlffwyEH1qocJJ9F6BluMi8PhmcCn/MY51kr34r83mft0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=N6jx1c1R4A42Cn/AHNz7SYn6gul/W2Oe+X1G6e4lkgleJqMmsY5g1a1S7R8EBqX1gI4iSSEmMgT8/Bh1aeKPhnA3GsOTj4wvJxXvH6XgdBXEwwzQC1Mv8feWmxHLqys9jaazAxEtDVcMO0otBmIQEiPGhW2X/TGszwoGlupsQV8=
- Reply-to: mpi-21@xxxxxxxxxxxxx
- Sender: owner-mpi-21@xxxxxxxxxxxxx
In the current MPI 2.0 document, MPI-2:2.5, p9:17-18 states:
"MPI provides certain predefeined 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. 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