From: HOLZHEU@XXXXXXXXXX X-Lotus-FromDomain: IBMDE To: gropp@XXXXXXXXXXX cc: mpi-bind@XXXXXXXXXXX,mpi-core@XXXXXXXXXXX,mpi-io@XXXXXXXXXXX,Message-ID: Date: Fri, 30 Apr 1999 18:14:19 +0200 Subject: Re: C++ MPI constants Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-UIDL: 668f6ba832ff149fa71aa6bdc67ff2cf Bill, Thanks for your comments. I would like you to consider the following issues: 4. Remove them and use the respective C versions (MPI_SEEK_SET etc.) ==================================================================== This will probably work for the "SEEK" constants since they have the same type (int) for the C and C++ bindings. Note, MPI constants do not have the same type in C and C++ in general. Using C constants with the C++ bindings will work in the most cases because of the language interoperability operators which are defined for the C++ MPI classes. However if you plan to remove all the MPI C++ constants (because we do not know how many additional offending constants exist) this probably will lead to some type conflicts. For example: /* MPI C-bindings */ ==================== typedef int MPI_Datarep_conversion_function(void*, MPI_Datatype, int, void*, MPI_Offset, void*); MPI_Register_datarep(..., >>>> MPI_Datatype_conversion_function <<<<< *read_conversion_fh, ...); MPI_CONVERSION_FN_NULL: Probably of type "MPI_Datarep_conversion_function" in most implementations! /* MPI C++-bindings */ ====================== typedef int MPI::Datarep_conversion_function(void*, MPI::Datatype&, int, void*, MPI::Offset, void*); MPI::Register_datarep(..., >>>> MPI::Datarep_conversion_function <<<<< *read_conversion_fh, ...); MPI::CONVERSION_FN_NULL: Probably of type "MPI::Datarep_conversion_function" in most implementations! So the C and C++ types of these constants are different and the C constants cannot be used here for the C++ bindings. Other examples are: - MPI_DUP_FN - MPI_NULL_COPY_FN - MPI_NULL_DELETE_FN - MPI_COMM_NULL_COPY_FN - etc. Using this solution (nr. 4) we would have the two alternatives: --------------------------------------------------------------- 1. Only the known offending Constants MPI::SEEK_SET etc. are removed + We can keep the standard almost as it is - We do not know how many offending constants exist and will come in the future - This decreases the orthogonality of the design of the C++ bindings because adhoc exceptions are introduced (we tell the programmer that he can use the C++ constants every time, except in the case of MPI_SEEK_SET, MPI_SEEK_CUR etc.) 2. All C++ constants are removed + orthogonal solution + The user has only to deal with one 'kind' of constants - The type problem I mentioned above (How do we solve this?) Michael ------------------------------------------------------------------------ OS/390 USS Parallel Environment Development Phone: +49-7031-16-2360, Fax -4240, Bld 71032-14-126 Email: holzheu@XXXXXXXXXX William Gropp on 04/29/99 11:05:54 PM Please respond to William Gropp To: Jeremy Siek cc: mpi-bind@XXXXXXXXXXX,mpi-core@XXXXXXXXXXX,mpi-io@XXXXXXXXXXX, Michael Holzheu/Germany/IBM,lumesdaine.1@XXXXXX, jsquyres@XXXXXXXXXX,jsiek@XXXXXXXXXX,treumann@XXXXXXXXXX, Reinhard Buendgen/Germany/IBM Subject: Re: C++ MPI constants At 09:28 AM 4/29/99 -0500, jeremy siek wrote: > >Michael Holzheu has brought to our attention a name conflict between >some macros in stdio.h (SEEK_SET, etc.) and the C++ MPI constants. > >He proposes two solutions. >1. Change all the C++ constants to lowercase, which would be more in > conformance with the style of the C++ standard libraries. > >2. Change just the offending constants by adding a "CPP_" prefix. > >Andrew Lumsdaine and I suggest that alternative #1 is the better choice. That's because #2 is so awful. Here's a more reasonable alternative 3. Change just the offending constants by adding an "MPI_" prefix. Of course, this makes the constants the same as the C versions, which doesn't seem so bad. That really makes the choices these: 1. Change to lowercase. 4. Remove them and use the respective C versions (MPI_SEEK_SET etc.) I'd prefer 4 slightly over 1. Bill