#3626(undetermined:new): add 'extern "C"' to headers
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Type: defect Status: new | Priority: wish Component: | Version: undetermined | unspecified Keywords: headers | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Your policy at the moment is to require applications to add 'extern "C"' to their C++ source files: http://trac.ffmpeg.org/wiki/Including%20FFmpeg%20headers%20in%20a%20C%2B%2B%... This is silly and annoying. It is the header file's job to present its interface consistently to applications. decklink_enc.h does this, the other headers should too. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Owner: Type: defect | Status: new Priority: wish | Component: Version: unspecified | undetermined Keywords: headers | Resolution: Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Comment (by ubitux): We have about 85 C public headers currently. Am I correct to assume that you are asking us to add a C++ boilerplate cruft for every one of them? Note that in addition to clutter the public header read by our downstreams, it will suggest that FFmpeg headers are C++ compatible, which is NOT the case because it uses C99 specific features in various places, which are not supported by the C++ language. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Owner: Type: defect | Status: closed Priority: wish | Component: Version: unspecified | undetermined Keywords: | Resolution: wontfix Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- Changes (by cehoyos): * keywords: headers => * status: new => closed * resolution: => wontfix Comment: The headers are C headers and I believe this documented. If you want to use the library with another compiler language, it is your responsibility to ensure the necessary steps are taken. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Owner: (none) Type: defect | Status: closed Priority: wish | Component: | undetermined Version: unspecified | Resolution: wontfix Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by jwakely): Could this wontfix decision be revisited? Would you accept a patch to add the necessary boilerplater? The current situation causes every C++ project that uses ffmpeg headers to deal with it, which then causes other problems downstream. The documented way to include ffmpeg headers from C++ sources violates the C++ standard. The standard says you can't include any standard header (such as {{{<math.h>}}}) inside an {{{extern "C"}}} declaration. Which C99 features are used which would cause a problem? Apparently it ''doesn't'' cause a problem, because many C++ projects such as Qt do include the headers. But they have to violate the C++ standard to do so, and the fall out from that can be harder for those projects to work around (it requires changes in the C++ standard library implementation to accommodate your policy). -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Owner: (none) Type: defect | Status: closed Priority: wish | Component: | undetermined Version: unspecified | Resolution: wontfix Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Cigaes): Carl Eugen Hoyos's answer is still valid. Adding this in our headers would imply we *support* it, which we do not. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Owner: (none) Type: defect | Status: closed Priority: wish | Component: | undetermined Version: unspecified | Resolution: wontfix Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by jwakely): Why couldn't you just continue to document that C++ is not officially supported, but still accept a patch so that it mostly Just Works, even though not supported? The reality is that people are already using your headers in C++ code, but they're forced to do so badly and in violation of the standard. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#3626: add 'extern "C"' to headers -------------------------------------+------------------------------------- Reporter: spraff | Owner: (none) Type: defect | Status: closed Priority: wish | Component: | undetermined Version: unspecified | Resolution: wontfix Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by jwakely): The current policy seems to be hostile to a large number of users. -- Ticket URL: <https://trac.ffmpeg.org/ticket/3626#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg