#3626 closed defect (wontfix)
add 'extern "C"' to headers
Reported by: | spraff | Owned by: | |
---|---|---|---|
Priority: | wish | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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%20application
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.
Change History (6)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Keywords: | headers removed |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
comment:3 by , 5 months ago
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).
comment:4 by , 5 months ago
Carl Eugen Hoyos's answer is still valid. Adding this in our headers would imply we *support* it, which we do not.
comment:5 by , 5 months ago
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.
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.