<div class="gmail_quote">On Tue, Jun 26, 2012 at 10:43 AM, Douglas Miller <span dir="ltr"><<a href="mailto:dougmill@us.ibm.com" target="_blank">dougmill@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the issue is just that how can a standard that does not specify how C++ fits into things (after ticket 281) then go on to define a data type in terms of C++ types? </blockquote><div><br></div><div>Is there an informal expectation that implementations will continue to provide an mpicxx wrapper?</div>
<div><br></div><div>I see no reason for anyone to be attached to std::complex (actually, I think it's very frequently a bad choice), but having *some* way to use complex types with a predefined (because one-sided cripples non-predefined) MPI_Op still seems important.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If there is a need for a C (not C++) complex datatype, that should be a new proposal. But that datatype should not, in my opinion, be defined in terms of something like std::complex. If a platform does not support something like C99 complex types, then it will have to implement complex types and ops itself, or be incomplete.</blockquote>
</div><br><div>As mentioned earlier, implementations making MPI_C_COMPLEX available independent of C99 would be sufficient. Otherwise we are stuck defining our own types for complex, and then can't use one-sided.</div>
<div><br></div><div>Some discussion of work-arounds: <a href="http://trac.mcs.anl.gov/projects/mpich2/ticket/1525">http://trac.mcs.anl.gov/projects/mpich2/ticket/1525</a></div>