[Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation

Erez Haba erezh at [hidden]
Mon Mar 16 05:53:26 CDT 2009



Dear Alexander,

Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer.

Thanks,
.Erez

-----Original Message-----
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander
Sent: Monday, March 16, 2009 3:43 AM
To: MPI 2.2
Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation

Hi,

I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will.

Best regards.

Alexander

-----Original Message-----
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp
Sent: Sunday, March 15, 2009 9:59 PM
To: MPI 2.2
Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation

Actually, MPI has taken the lead in a number of areas, including cross- 
language compatibility, to say nothing of the existence of MPI itself.

And MPI has taken great pains to be the *greatest* common  
denominator.  Const simply captures the previously required semantics  
of the interface in the syntax, and is consistent with the MPI spirit.

Bill
On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote:

> On Mar 13, 2009, at 9:40 AM, William Gropp wrote:
>
>> First, this is a chicken-and-egg problem; the low level
>> interfaces are unlikely to change to add const unless there is some
>> application that will take advantage of that (and internally, if  
>> their
>> semantics allows it and their compiler can support it, they'll just
>> cast to add the const).  So MPI should take the lead, particularly
>> since using const also provides information to the user.
>>
>
> This is a very scary statement to me.  MPI has not traditionally
> "taken the lead" on forcing issues with other interfaces (look where
> it has gotten us with Fortran...).  Indeed, MPI has taken great pains
> to be the lowest common denominator across a variety of language,
> platforms, and operating systems.
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign

_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22



More information about the Mpi-22 mailing list