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
> 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).
> 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_*
Right, MPI::SEEK_* is never used.
- application/pgp-signature attachment: stored