Therefore, it seems to me, we have a number of possibilities
1) Forbid const in mpi.h
+ it's pretty much where we are now
+ it's consistent with (at least one) compiler which accepts
prototypes, but not const !
+ profile writers have something consistent to write to
- it hurts users who are trying to enforce const correctness
2) Require const in mpi.h
+ it allows users to write const correct code.
+ profile writers have something consistent to write to
3) Allow either consistent const, or no-const in mpi.h.
+ no need to change existing header files
- profile writers have a problem (but it can at least be fixed by
#define __MPI__CONST const
or
#define __MPI__CONST
and using __MPI__CONST in the profile function declarations).
4) Anarchy, allow const on some functions and non-const on other
"const-able" functions.
- no advantages for anyone.
Thinking about 3, does suggest another possible solution, which is
to require mpi.h to #define MPI_CONST (or whatever the naming police
would like this to be called).
So how about this for a proposal :-
1) mpi.h must either consistently use const, or consistently not use
const.
2) mpi.h must contain a definition of the pre-processor symbol
MPI_CONST, which must have one of the two values "const" or ""
(without the "" of course), set in the appropriate way.
The advantages of this are :-
1) The only change needed to existing mpi.h files is the addition of a
suitable definition of MPI_CONST.
2) Profile code can be written to be consistent with const or
non-const headers.
-- Jim
James Cownie
Dolphin Interconnect Solutions
Phone : +44 117 9071438
E-Mail: jcownie@dolphinics.com