From: Jeff Squyres Date: January 19, 2008 7:02:46 PM CST To: mpi-21@XXXXXXXXXXXXX Cc: "mpi-21@cs.uiuc.edu" Subject: Re: [mpi-21] const C++ MPI handles (take 2) Reply-To: mpi-21@XXXXXXXXXXXXX Because I have a mail proposal pending to restore the "const" that was [erroneously, IMHO] removed in ballot 2. :-D On Jan 19, 2008, at 5:59 PM, Erez Haba wrote: > If the 'const' was removed in ballot 2 whey do you want to leave > the text that refers to it? > > -----Original Message----- > From: owner-mpi-21@mpi-forum.org [mailto:owner-mpi-21@mpi- > forum.org] On Behalf Of Jeff Squyres > Sent: Saturday, January 19, 2008 11:17 AM > To: mpi-21@mpi-forum.org > Cc: mpi-21@XXXXXXXXXXX > Subject: Re: [mpi-21] const C++ MPI handles (take 2) > > Well, we pretty much have so far. :-) > > The const was removed in ballot 2, but I wonder how many people > actually noticed (I didn't, until a few days ago). > > > > On Jan 19, 2008, at 1:21 PM, Erez Haba wrote: > >> I agree, const is the better way to implement. The question is: do >> you want to *force* the optimized implementation? >> >> -----Original Message----- >> From: owner-mpi-21@mpi-forum.org [mailto:owner-mpi-21@mpi-forum.org] >> On Behalf Of Jeff Squyres >> Sent: Friday, January 18, 2008 5:49 PM >> To: mpi-21@mpi-forum.org >> Cc: mpi-21@XXXXXXXXXXX >> Subject: Re: [mpi-21] const C++ MPI handles (take 2) >> >> Yes, that's the way the original C++ bindings were implemented. But >> it's not required or necessary to do that; that C errhandler could >> easily be cached somewhere else. >> >> More specifically, isn't it better to have a const object to allow >> for >> compiler optimizations? (I'm not a compiler guru, but I thought the >> point of why we originally made the C++ handles be const was on the >> argument for potential compiler optimizations) >> >> >> On Jan 18, 2008, at 8:35 PM, Erez Haba wrote: >> >>> 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@mpi-forum.org [mailto:owner-mpi-21@mpi-forum.org] >>> On Behalf Of Jeff Squyres >>> Sent: Friday, January 18, 2008 11:14 AM >>> To: mpi-21@mpi-forum.org >>> 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 >>> >> >> >> -- >> Jeff Squyres >> Cisco Systems >> > > > -- > Jeff Squyres > Cisco Systems > -- Jeff Squyres Cisco Systems