[Libav-user] Compile with g++

[Michael Chisholm]

On 10/9/2013 8:33 PM, Carl Eugen Hoyos wrote:
> Michael Chisholm <chisholm at ...> 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