Re: [Mpi-forum] C++ types inaccessible after #281
Yes, I think that Jed has a good point here. There are a few C++-specific datatypes for which it would be worth introducing new C datatypes (e.g., MPI_CXX_COMPLEX). It's too bad that no one realized this until now, because this won't make the MPI-3 deadline. But it could be part of MPI-3.1 or errata, or some such. Is there a C++ person out there who could draft a proposal about this? On Jun 26, 2012, at 1:02 AM, Jed Brown wrote:
I'm all for getting rid of the C++ bindings and see no compelling reason for anyone to use them.
Predefined types are inconsequential to MPI-1 functionality, but they are special for one-sided, so availability of types is highly relevant to applications. This is a non-cosmetic change imposed by #281 that doesn't seem to have been discussed.
On Jun 25, 2012 8:51 PM, "Fab Tillier" <[email protected]> wrote: Ah, thanks, sorry for being dense (I'm not familiar with the C++ bindings as we don't ship them for MSMPI).
Ticket 281 removes the entire C++ bindings from the standard, MPI::COMPLEX included. You'd need to convince your MPI library vendor to keep supplying you with an MPI-2.2 compliant version of the C++ bindings (which is still allowed by ticket #281).
Hopefully someone with more experience with the C++ bindings can chime in, but I'd expect the answer to your original question is yes, ticket #281 intentionally removes all C++ support from MPI-3.
-Fab
Jed Brown wrote on Mon, 25 Jun 2012 at 21:31:55
MPI::COMPLEX is not the same as MPI_C_COMPLEX (and the latter is not available on systems without C99).
On Jun 25, 2012 8:21 PM, "Fab Tillier" <[email protected]> wrote: Hi Jed,
Maybe I'm not following you, but what predefined MPI datatype supports std::complex today? My understanding is that there is no support for std::complex in MPI today, and that ticket 281 does not change this at all.
Thanks, -Fab
Jed Brown wrote on Mon, 25 Jun 2012 at 20:42:53
I see that std::complex will not be accessible in a predefined type if #281 passes in its current form. Do you intend for there to be a supported/recommended way for a C++ caller to get a complex predefined (so that one-sided can be used) type? Note that C99 is not a subset of any C++ and C99 complex cannot be used portably from C++ (even with compiler suites that happen to support both).
On Jun 25, 2012 7:07 PM, "Fab Tillier" <[email protected] <mailto:[email protected]> > wrote: Hi Jed,
Jed Brown wrote on Mon, 25 Jun 2012 at 16:43:54
Is it intended that #281 would make std::complex inaccessible? Should there be a MPI_CXX_COMPLEX, MPI_CXX_DOUBLE_COMPLEX, MPI_CXX_LONG_DOUBLE_COMPLEX, and (possibly) MPI_CXX_BOOL?
I don't think ticket #281 does anything with respect to std::complex accessibility. The MPI standard defines the MPI_C_COMPLEX and family as mapping to the C99 _Complex type (see Table 3.2, Predefined MPI datatypes corresponding to C datatypes). The standard is clear that there are no corresponding C++ bindings.
Note that C99 complex is not a substitute because Microsoft does not implement it and it has different semantics regarding numerical stability. (Well, C99 semantics are specified and useful, std::complex stability is not specified by any C++ standard and in practice, is not implemented in a stable way.) This is not such a big deal for use with collectives because user-defined MPI_Ops can be used, but only predefined types can be used with one-sided operations, so presence of complex datatypes (or lack thereof) is relevant to applications.
The fact that Microsoft does not support C99 is lame. You can probably get away using std::complex as a stand-in for C99 _Complex (but then you're on your own), or move to a compiler that does (I believe the Intel compiler supports C99 on Windows).
-Fab
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
participants (1)
-
Jeff Squyres