Skip to content

Remove C++ Bindings #281

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mpiforumbot opened this issue Jul 24, 2016 · 48 comments
Closed

Remove C++ Bindings #281

mpiforumbot opened this issue Jul 24, 2016 · 48 comments
Assignees
@mpiforumbot
Labels
MPI 3.0 New routine(s) Text committed Ticket complete
Milestone
2012/09/19 Vienna...

Comments

@mpiforumbot
Copy link
Collaborator

mpiforumbot commented Jul 24, 2016 •
edited
Loading

Originally by ftillier on 2011-06-23 17:13:11 -0500

This ticket removes the deprecated C++ bindings.

Motivation

The C++ bindings are problematic for binary distributions of implementations because there is no standard for C++ name mangling. This requires implementors to either ship multiple binaries (one set of binaries per target compiler), restrict customer choice in compiler suites, or ship the C++ bindings in source form, requiring them to be layered above the C bindings.

Further, new MPI-3.0 routines have no C++ bindings, requiring C++ applications to use the C bindings.

Backward Compatibility

Applications requiring support for these can request support for them from their MPI implementations. There are no problems with concurrent support of different versions of the standard, allowing implementations to be compliant with both MPI 2.2 as well as MPI 3.0. The C++ bingings can thus be provided via MPI 2.2 support, while new MPI-3.0 specific functionality can be used via the C bindings.
@mpiforumbot mpiforumbot self-assigned this Jul 24, 2016
@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2011-07-20 20:41:12 -0500

As expected, there was much discussion about this at the Forum.

The usual points were brought up:

  • There are existing apps out there that use the C++ bindings (e.g., DOE apps and Intel has some customers that use them)
  • Rolf cited the MPI survey:
    • 165 respondents said they have C++ apps that use the MPI C++ bindings
    • 550 said they didn't have C++ apps that use the MPI C++ bindings
    • 107 said they didn't know if they have C++ apps that use the MPI C++ bindings
  • There was discussion that it would be good to fix the dichotomy of having C++ for some MPI API functions, but not all (i.e., not new 3.0 API functions) either by removing the C++ bindings or undeprecating them.
  • There is an ancient ticket to undeprecate the C++ bindings that has not moved in over a year.
  • Surprisingly (to me, anyway), some DOE personnel said that the current state of deprecated C++ was perfect for them:
    • Their existing C++ MPI applications will just use the C bindings for new MPI-3 functionality (and those app developers are ok with that)
    • New MPI applications will not use the C++ MPI API
    • Hence, deprecated is perfect for them -- they don't want to undeprecate, and they don't want to remove.
  • I took 2 straw polls. Poll !Fortran MPI_*_ERRHANDLER callback functions are varargs #1:
    • Delete the C++ bindings (probably moving them off to a "deleted" chapter, per the idea raised in Make C++ bindings optional #279): 8
    • Keep the C++ bindings as they are now (i.e., deprecated): 4
    • Abstain: 8
  • Straw poll !MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1 #2:
    • Undeprecate the C++ bindings: 5
    • Keep the C++ bindings deprecated: 10
    • Abstain: 6
  • These are not conclusive straw polls because of a lot of abstains, but at least half of the attendees want to keep the C++ bindings deprecated, and 2/5 want to delete the C++ bindings altogether.

@mpiforumbot
Copy link
Collaborator Author

Originally by ftillier on 2011-09-01 13:04:35 -0500

Withdrawing this ticket, as ticket #279 makes the C++ bindings optional and is far less contentious, as well as a lot easier in terms of LaTeX changes.

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2011-10-25 14:00:51 -0500

accepting as potential work to enumerate chagens required to delete C++ bindings

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2011-11-02 08:59:27 -0500

Added a first-pass at removing the C++ bindings. I created a new chapter "Removed Language Interfaces" and moved all C++ function prototypes there, as well as the design discussion and listings of Language Constants.

In most cases, the original text is marked with "ticket281" and the removed C++ text colored as DELETE. There were some impracticalities so tables with removed C++ columns and some "trivial" references to things like "C/C++" are not marked, however I have revision history in my repository to track those.

I'm not sure I captured the original intent for "removing C++ bindings", but it is a start. What's the next step?

@mpiforumbot
Copy link
Collaborator Author

Originally by ftillier on 2011-11-02 10:04:36 -0500

I'd suggest naming the new chapter "Removed Interfaces" to not make it programming language specific. For example, there is a ticket I started, to remove some of the deprecated MPI-1 routines. For these, all bindings would be removed, and it would be nice if this new chapter could capture these too.

I think the language should be faily brief in the deleted chapter. It should reference the names of the objects/APIs/constants/etc, say they were deleted, and just reference the last standard that included them.

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2011-11-29 14:00:07 -0600

Updated svn with new name for removed interfaces section. attached new pdf.

@mpiforumbot
Copy link
Collaborator Author

Originally by ftillier on 2011-12-02 13:05:37 -0600

Hi Doug,

I've reviewed the document, and it looks good overall. Here's the few comments I came up with:
Page 15, line 15: No need for a blank line with a period
Page 16, line 10: Should still say "In C one uses MPI_Offset."
Page 514, Line 38: The footnote should go away.
Page 518, probably a LaTeX issue, but it does not show as new text.

@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-01-06 13:23:55 -0600

Doug -- a few comments on the PDF.

  • p16: removes "In C one uses MPI_Offset" -- don't we still need this?
  • p490: s/Chatper/Chapter/
  • p491: s/may only be provided/may be provided/
  • p491: WRT: "Where an MPI-3.0 interface does not have a corresponding C++ interface,", no MPI-3.0 interfaces will have C++ bindings
  • p514: caption on "Null Handles" table needs to change
  • p539: "moved entire section on C and C++ interoperability into REMOVED section(s)" -- where? I don't see it in chapter 16

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2012-01-06 13:40:23 -0600

Replying to jsquyres:

Doug -- a few comments on the PDF.

  • p16: removes "In C one uses MPI_Offset" -- don't we still need this?
    I took this sentence to be a comparison between C and C++. I don't think it makes any sense to just say "In C one uses MPI_Offset." since it is an example on how to get a C++ name from a C name.
  • p490: s/Chatper/Chapter/
    Fixed.
  • p491: s/may only be provided/may be provided/
    I don't know for sure where that text originated, but since it doesn't pertain to C++ bindings I did not examine it. I think that sort of change is for another ticket?
  • p491: WRT: "Where an MPI-3.0 interface does not have a corresponding C++ interface,", no MPI-3.0 interfaces will have C++ bindings
    Removed text.
  • p514: caption on "Null Handles" table needs to change
    This table was simply moved from the "Constants" section and modified to refer only to C++ names. Should both tables (C/FORTRAN and Removed C++ sections) have their heading changed? I'm not sure that's within the scope of this ticket.
  • p539: "moved entire section on C and C++ interoperability into REMOVED section(s)" -- where? I don't see it in chapter 16
    That section was originally moved to the Removed Interfaces section, but later I got feedback saying it should be deleted. I'll change this note accordingly.

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2012-01-06 14:58:20 -0600

updated attached document with "ticket0" changes from Jeff Squyres.

@mpiforumbot mpiforumbot reopened this Jul 24, 2016
@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-01-10 22:10:08 -0600

Proposal was read in the Jan 2012 Forum meeting. Even more textual cuts were proposed by the Forum. Additionally, several C++ sections were missed that need to be cut.

So the proposal will be revised a bit more and brought up again for a reading at the next meeting.

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2012-01-11 16:47:56 -0600

Attachment added: mpi3-ticket281-report.pdf (3677.0 KiB)
MPI3 preliminary report with C++ bindings moved to REMOVED section

@mpiforumbot
Copy link
Collaborator Author

Originally by RolfRabenseifner on 2012-07-18 06:53:10 -0500

Passed July 17, 2012 with 15 YES, 4 NO, 2 ABSTAIN.

@mpiforumbot
Copy link
Collaborator Author

Originally by RolfRabenseifner on 2012-07-18 07:04:02 -0500

The sources for this ticket, i.e.,

  • tha attached latest pdf
  • and the source on svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-compat/ticket-281/
    may be in a terrible state. (If this is only one location, then it is now detected.)

There are part(s) that are deleted from the source without any notification (e.g. macro or some comments telling else that this is a change due to #281).

A grep 281 /.tex does not show all modified locations!

Example:

  • MPI-2.2 A.1.3, the C++ prototypes section, MPI-2.2 p527:42 - p528:32

I hope, that this is the only such modification without notification.

We need that this is clarified by the ticket responsibles, otherwise a correct implementation in the approved latex source is hard.

@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-07-18 07:12:05 -0500

What you're saying is that the 281 authors didn't consistently use \MPIdelete and whatnot. That is correct.

I actually went through a PDF built from that tree and manually added the relevant \MPIdelete (etc.) in the bindings chapter. It was a little annoying, but I think I found all the Right places where 281 removed text.

@mpiforumbot
Copy link
Collaborator Author

Originally by dougmill on 2012-07-18 07:22:35 -0500

This was discussed, at least at all the readings I did. No objections were raised at the time. That branch was created with initial, un-modified, files from the trunk at that time. Diffing between the initial rev and current rev should show all changes made.

So, are we keeping the \MPIdelete, etc, macros for the "proof" copy of the doc? I was under the impression that the doc would be unreadable with all the annotations from all tickets kept in it.

@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-07-18 07:33:23 -0500

Yes, the macros serve multiple purposes:

  • Making it easy for chapter authors to find where all the changes were made
  • Making it possible to proof exactly what was removed / changed / etc.

Since they're macros, it's easy to produce proofing copies for internal use in the forum (i.e., showing all the deleted text, etc.), but then also with the flick of a switch, not show all the deleted text (etc.) and generate a final, clean copy for production that doesn't include all the deleted text (etc).

@mpiforumbot
Copy link
Collaborator Author

Originally by RolfRabenseifner on 2012-07-18 07:44:15 -0500

Replying to dougmill:

... Diffing between the initial rev and current rev should show all changes made.

A svn diff between which svn releases of
svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-compat/ticket-281/
must be done to catch exactly the changes you did?

@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-07-18 07:50:53 -0500

Yes. For example:

svn diff -r 969:HEAD https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-compat/ticket-281/chap-binding

shows the cumulative diff in the bindings chapter of all the changes made on the 281 branch. Edit the URL to show whichever chapter you want, or remove the chapter directory to show all changes.

@mpiforumbot
Copy link
Collaborator Author

Originally by htor on 2012-07-18 12:42:18 -0500

Small updates to coll chapter based on Howard's comment (thanks).

--> http://www.unixer.de/sec/mpi-report.pdf

Thanks,
Torsten

@mpiforumbot
Copy link
Collaborator Author

Originally by buntinas on 2012-07-18 14:46:13 -0500

Applied to Info chapter in r1422.

-d

@mpiforumbot
Copy link
Collaborator Author

Originally by schulzm on 2012-07-18 16:02:24 -0500

Applied to Environment Chapter 8

@mpiforumbot
Copy link
Collaborator Author

Originally by RolfRabenseifner on 2012-07-18 18:19:09 -0500

Committed to approved/chap-appLang as r1440

@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-07-18 18:24:01 -0500

The removed chapter reviewed ok.

@mpiforumbot
Copy link
Collaborator Author

Originally by jsquyres on 2012-07-18 18:24:38 -0500

All text appears to have been committed; moving to the "Waiting for PDF reviews" state.

@mpiforumbot
Copy link
Collaborator Author

Originally by buntinas on 2012-07-18 18:37:40 -0500

Topo chapter reviewed and fixed. OK

@mpiforumbot
Copy link
Collaborator Author

Originally by anhvo on 2012-07-18 18:42:48 -0500

pt2pt reviewed. OK

@mpiforumbot
Copy link
Collaborator Author

Originally by buntinas on 2012-07-18 19:21:58 -0500

Bindings chapter reviewed and fixed. OK

@mpiforumbot
Copy link
Collaborator Author

Originally by anhvo on 2012-07-19 12:02:30 -0500

In clean doc R1473 I'm still seeing a couple C++ bindings in chapter 13 (I/O). Page 541 and 542 (MPI_Datarep_extent_function and MPI_Datarep_conversion_function)

@mpiforumbot
Copy link
Collaborator Author

Originally by rsthakur on 2012-07-19 13:07:30 -0500

Also disabled the \mpicpptypedefbind and \mpicpptypedefemptybind macros to remove the above C++ typedefs in the I/O chapter

@mpiforumbot mpiforumbot mentioned this issue Jul 24, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mpiforumbot mpiforumbot

Labels
MPI 3.0 New routine(s) Text committed Ticket complete
Projects
None yet
Milestone
2012/09/19 Vienna, Austria
Development

No branches or pull requests
1 participant
@mpiforumbot