On Thu 2008-10-16 08:21, Jeff Squyres wrote: > FWIW: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/20 is a > placemarker for discussion for the upcoming MPI Forum meeting (next > week). > > Also, be aware that OMPI's 1.2.7 solution isn't perfect, either. You > can see from ticket 20 that it actually causes a problem if you try to > use SEEK_SET in a switch/case statement. But we did this a little > better in the trunk/v1.3 (see > https://svn.open-mpi.org/trac/ompi/changeset/19494); this solution *does* > allow for SEEK_SET to be used in a case statement, but it does always > bring in <stdio.h> (probably not a huge deal).
I see. > The real solution is that we're likely going to change these names to > something else in the MPI spec itself. And/or drop the C++ bindings > altogether (see http://lists.mpi-forum.org/mpi-22/2008/10/0177.php). Radical. I don't use the C++ bindings anyway. I especially like proposal (4) Data in User-Defined Callbacks. On a related note, it would be nice to be able to call an MPI_Op from user code. For instance, I have an irregular Reduce-like operation where each proc needs to reduce data from a few other procs (much fewer than the entire communicator). I implement this using a few nonblocking point-to-point calls followed by a local reduction. I would like my special reduction to accept an arbitrary MPI_Op, but I currently use a function pointer. Having a public version of ompi_op_reduce would make this much cleaner. > Additionally -- I should have pointed this out in my first mail -- you > can also just use MPI_SEEK_SET (and friends). The spec defines that > these constants must have the same values as their MPI::SEEK_* > counterparts. Right, MPI::SEEK_* is never used. Thanks Jeff. Jed
pgpH59WXzCO57.pgp
Description: PGP signature
