On 10/9/2013 8:33 PM, Carl Eugen Hoyos wrote:
Michael Chisholm <chisholm@...> writes:
So my point to all this is, the ffmpeg-2.0.1 headers
aren't completely C++-friendly
I don't think this is correct as such:
The headers are neither C++-friendly nor C++-unfriendly,
they are simply C headers and exactly the same
limitations apply than when using any other (non-trivial)
C headers from a C++ program.
I wasn't trying to make "C++-friendliness" an ffmpeg-specific metric.
So yes, the same limitations apply when using ffmpeg as any other C
library, from a C++ application.
I think you can talk about C++-friendliness of a C header in general
though. I think it's legitimate to think about the overlap between the
C and C++ languages and to what extent a given piece of C code (even in
a header) stays within the overlap or goes outside. I think C structs
and function prototypes are usually not going to be problematic (I'm not
an expert though). Areas I can see where you can tilt into
C++-unfriendliness include inline functions and macros.
Issues with inline code should be obvious: inline function definitions
are given in headers, which exposes them to the C++ compiler. Macros in
a C header could also expand to C code which could cause compile errors
with a C++ compiler. How much of a problem the latter is depends on
whether or not you really need to use the macro. You have the luxury of
opting not to use a macro so the C++ compiler never sees the problematic
C code and errors out. Not so with inline functions afaik.
The fact that some explicit casting is necessary
in C++ is completely orthogonal to the C++-
"friendliness" of the FFmpeg headers afaict.
The compile error I originally quoted is a poor example of the
C++-friendliness of the headers. But I also had intended it as part of
the question to James regarding which errors he was seeing. As you
note, that casting error with av_mallocz() is not actually a header
issue at all. That's one reason I decided to post a followup note. I
realized that original "test" didn't do what I had intended. The
followup addressed C++-friendliness better.
Do I understand correctly that you cannot use the
av_ts2timestr() macro from C++ but that it is not
used inside of FFmpeg in a way that makes using
one of the libraries or one of the headers
impossible?
(If you know how to fix it, consider sending a
patch, assuming it does not slow down the macro
for C, such a change is useful imo.)
Yes, that is correct. I don't know of an easy way to fix it; C++ just
doesn't let you take addresses of temporaries. It seems like C++ treats
it analogously to:
void f(const int *i){...}
f(&1);
i.e. trying to take the address of 1.
Andy
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
