> The issue is implicitly mixed language programming between C and C++.
> If one were only talking C++, then presumably, one would not care
> about the C binding. You should require the use of the C++ binding
> only.
This is not possible in the real world. Consider a C++ programmer
wanting to use Petsc (for instance).
> To get compatibility...
> The object MPI could be the name space for all MPI-related stuff.
> MPI.whatever or MPI->whatever ... then, it could co-exist with
> the C name space, and interactions between the class form, and the C
> form would have to be done with global functions.
I don't understand this suggestion. The proposed C++ bindings use
MPI_Comm, MPI_Group, etc., as the classes. Are you suggesting to
instead use a single class named "MPI"? This seems to contradict your
later suggestion about design for inheritance/reuse.
> Rules for C/C++ interchange (just like between C and Fortran) must be
> worked out.
I think the C/C++ interchange issue is different than the C/Fortran
issue. For one thing, since C and C++ are so intimately related (in
particular, C is a proper subset of C++), the C and C++ bindings
should inter-operate in like fashion.
I think Jim Cownie's suggestion of giving the objects different names
so that there is no conflict with the C name space solves all the
inter-operability problems and seems not to introduce any new ones.
Best Wishes,
Andrew Lumsdaine