From: Erez Haba Date: January 18, 2008 7:35:21 PM CST To: "mpi-21@mpi-forum.org" Cc: "mpi-21@cs.uiuc.edu" Subject: RE: [mpi-21] const C++ MPI handles (take 2) Reply-To: mpi-21@XXXXXXXXXXXXX For example an implementation might choose to cache the error handler for MPI::COMM_WORD (in the MPI::Comm object) and call it itself on error so it can pass in the right object to the error handler. Thus requiring MPI::COMM_WORLD not to be const. -----Original Message----- From: owner-mpi-21@XXXXXXXXXXXXX On Behalf Of Jeff Squyres Sent: Friday, January 18, 2008 11:14 AM To: mpi-21@XXXXXXXXXXXXX Cc: mpi-21@XXXXXXXXXXX Subject: [mpi-21] const C++ MPI handles (take 2) On Jan 18, 2008, at 2:02 PM, Erez Haba wrote: > Okay; about one issue at a time. Changing mail subject to reflect the discussion... > *For this sentence* it does not matter what's a common usage for C++ > global variables. Some MPI implementations would need to have non- > const qualified global objects. Why? As I understand it, most (all?) MPI C++ implementations currently only require some objects to be non-const because of the standard-related issue that was already raised (Set_attr(), Set_name(), Set_errhandler() methods not having const variants). Is there a reason that an implementation would *need* MPI handles to be non-const? Per my prior mail, I believe that the standard should specify that some of the methods on these classes should have const and non-const variants, and then it should be fine to require that the predefined handles be const. So the question is still open: what's common practice in the C++ community regarding const/non-const global variable specification? This question will be moot if you can demonstrate that an implementation would need non-const C++ MPI predefined handles. -- Jeff Squyres Cisco Systems