I think this is pointing out a fundamental issue. You're presuming
that the C++ MPI_Comm is a different object from the C MPI_Comm (and
so on). Why ?
This implies that the C++ "binding" is actually rather more than that,
it's more like a re-implementation, since it is using different
structures to hold the information.
I was expecting that these data types would be the same. Remember that
"A structure *is* a class declared with the class-key 'struct'; its
members and base classes are public by default." (C++ Programming
Language Rule 9). [my emphasis].
An implication of this is that a struct and a class have identical
store layouts. (Which will be the same as that generated in C provided
that the class has no virtual methods).
Therefore I would have expected the C++ MPI_Comm to be exactly the
same as the C MPI_Comm, but with a whole set of non-virtual member
functions defined on it. Most of these would then look something like
int MPI_Comm::Send(void* buf, int count, MPI_Datatype &datatype,
int dest, int tag)
{
return MPI_Send(buf, count, datatype, dest, tag, this);
}
The inter-operability and name clash problems then disappear, and
implementing the C++ binding becomes rather easy...
> Also please note that the "const" constants issue hasn't been fully
> resolved yet -- we'd like to hear from some more implementers first.
> Particularly, the int vs. enum issue has not been resolved yet.
>
> Here's my $.02 on the issue: It shouldn't matter whether (for
> example) the return codes are const ints or const enums, because
> both are constant in the eyes of the compiler, both can be assigned
> initial values, and both provide better type safety than #define.
Right. The standard doesn't need to lay down whether the values are
const ints or enum names from an anonymous enum. In effect the two
things are indistinguishable for the uses we want to put them
to, since an enum silently converts to a const int where required.
Though they are in general distinguishable, for instance
const int i = 10;
const int * const p = &i;
is valid, whereas
enum { i = 10 }
const int * const p = &i;
is not.
If we want to allow enums, we should therefore at least state that you
cannot take the address of one of these constants.
-- Jim
James Cownie
BBN UK Ltd
Phone : +44 117 9071438
E-Mail: jcownie@bbn.com