It's not unintuitive -- it is consistent with all the rest of MPI (even
the datatype constructors -- see below). One MPI opaque object is being
used to create another, so the "original" object (i.e. the IN object)
must have the function as a member. I don't recall any other calls in
MPI in which an MPI opaque object is both an OUT variable and "this".
This was *soundly* rejected by the forum -- it was an earlier C++
proposal.
> too long for a function that will be in
> common use,
Too long? What about MPI_FILE_GET_BYTE_OFFSET?
MPI_WRITE_EXPLICIT_ALL? MPI_READ_SHARED_ORDERED_END? (etc.) These are
all even longer...
> and incorrectly focused on comm as the apparent
> object of the function.
I disagree -- it reinforces the concept that the open file's scope is on
a communicator.
Let me remind everyone of the proposed binding:
MPI::File MPI::Comm::Open_file(...whatever...)
So user code would look like (note the comparison to a regular fopen):
void
foo()
{
MPI::File mpi_fp;
FILE *os_fp;
mpi_fp = MPI::COMM_WORLD.File_open(...);
os_fp = fopen(...);
}
The assignment form of the creation looks pretty similar to the way that
people are used to opening files, don't you think? Putting the
MPI::File as the OUT variable would look like this:
void
foo()
{
MPI::File mpi_fp;
mpi_fp.Open_file(MPI::COMM_WORLD, ...);
}
That's nice, but not as nice as the assignment form, above.
> I don't agree that MPI::File is not an acceptable scope
> for the open call; MPI::Datatype works fine as a scope for
> all the datatype constructors, even though the datatype
> object doesn't exist when the functions are called. (Presumably
> these are static member functions.) If one wanted to follow
This is only somewhat true -- the only reason that the datatype
functions are scoped on the MPI::Datatype objects is because the
MPI::Datatype is the originating MPI opaque object; again, one MPI
opaque type is being created from another. They just happen to both be
the same type. But it does follow the same pattern that I am proposing
for the file open call:
MPI::Datatype MPI::Datatype::Create_contiguous(int count) const
That is, the "oldtype" parameter is "this", and the "newtype" is the
return value. The OUT parameter is the return value, not "this".
> the rules to the letter, I suppose MPI::File::create would
> be acceptable. Unfortunately, "create" already means something
> else in the context of file manipulation.
Even if "create" is used, it still has to follow the same pattern used
in the rest of MPI -- if an MPI opaque object is created from another
MPI opaque object, it must be on the scope of the IN parameter; the OUT
parameter is the return value.
> While MPI_Comm_open_file may be consistent, I don't
> think it's intuitive, and in my opinion the main reason to
> worry about consistency at all is that it makes the names
> easier to understand and predict. MPI_Open is already a
> name that's easy to understand and predict, so we don't
> need to mess with it. What's more, I think we would get
> far more complaints from users about a name like
> MPI_Comm_open_file than we ever would about MPI_Open.
Looking at the name as "an MPI::File is created from an MPI::Comm", it
is understandable and predictable. A file's scope is on a communicator,
so this just reinforces the scope. Sorry if I'm beating a dead horse,
but I'm very biased towards scoping issues because it is so important to
C++.
And user complaints? When was the last time that the forum worried
about user complaints? ;-) Seriously though, I don't think that anyone
can complain about it any more than they complain about the other 30
character function names.
> As for using "File" in names like MPI_File_read_explicit_all,
> I would point out that Rule 2 explicitly permits the object
> to be omitted from the C and Fortran names if the operation
> can only be applied to one object. Thus MPI_Read_explicit_all
> is completely legal.
Not quite; rule 2 is for the rationalization of all the MPI-1 names.
There was nothing that we could do about the MPI-1 names (they are
written in stone, and are effectively unchangable), and we had to make
the rules that would "accept" the MPI-1 names (and we really had to
stretch to make then up -- rule 2 was solely for that purpose). Even
so, there were a collection of MPI-1 names that we couldn't get to fit
any rules; they're clearly broken.
But one of the main goals of these rules is to prevent name clashes in
the future; isn't it concievable that there could be other MPI objects
that we "read" and "write" to, perhaps in MPI-3? This is why the name
"file" should be in all the names for the IO.
{+} Jeff Squyres
{+} squyres@cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to Notre Dame for 4 years and ended up staying for a
decade."