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).
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).
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.
On Oct 16, 2008, at 7:57 AM, Jed Brown wrote:
On Thu 2008-10-16 07:43, Jeff Squyres wrote:
On Oct 16, 2008, at 6:29 AM, Jed Brown wrote:
Open MPI doesn't require undef'ing of anything. It should also not
require any special ordering of include files. Specifically, the
following codes both compile fine for me with 1.2.8 and the OMPI SVN
trunk (which is what I assume you mean by "-dev"?):
That's what I meant. This, works with 1.2.7 but not with -dev:
#include <iostream>
#undef SEEK_SET
#undef SEEK_CUR
#undef SEEK_END
#include <mpi.h>
If iostream is replaced by stdio, then both fail.
This is actually a problem in the MPI-2 spec; the names
"MPI::SEEK_SET"
(and friends) were unfortunately chosen poorly. Hopefully that'll be
fixed relatively soon, in MPI-2.2.
It wasn't addressed in the MPI-2.1 spec I was reading, hence my
confusion. When namespaces and macros don't play well.
MPICH chose to handle this situation a different way than we did, and
apparently requires that you either #undef something or you #define
an
MPICH-specific macro. I guess the portable way might be to just
always
define that MPICH-specific macro. It should be harmless for OMPI.
I'll go with this, thanks.
FWIW, I was chatting with the MPICH developers at the recent MPI
Forum
meeting and showed them how we did our SEEK_* solution in Open MPI.
Certainly the OMPI solution is better for users.
Jed
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
Cisco Systems
