[FFmpeg-devel] [RFC] extern "C" usage

[Ulrich von Zadow]

Alex Beregszaszi schrieb:
> Hi,
> 
>>> and a
>>> consensus to remove them seems to exist, I would say remove them.  I'm
>>> all for it.
>> I'm not an ffmpeg developer, but someone who has been using ffmpeg in
>> open source sw (www.libavg.de) for quite some time. So, it's your choice
>> whether to remove this code, but I'd like to add my 2c to the discussion:
>>
>> At the moment, it's no harder to use ffmpeg from C++ than it is from C
>> (We're doing it), and that's very good. Removing the extern "C" markings
>> would change that. It would remove maybe 20 lines from ffmpeg and
>> require every library that uses ffmpeg from C++ to add these lines
>> again. That's a lot of duplicated code and hence wasted effort.
>>
>> Are you sure you want that?
> 
> Read the first emaul carefully. Some public headers of FFmpeg do include
> it, while others not, like aes.h. We have two choices, pollute the
> source allover with extern, or let this be done by the C++ user (note,
> I'm using ffmpeg in a C++ project, in VisualC++ now, so I'm included in
> that group).
> 
> That means, people are already requested to add some extern "C" lines in
> their code, not to speak about __STDC_CONSTANT_MACROS definition, and
> probably others.
> 
> In its current form, it does more harm then benefits, people just think
> C++ is something well supported in FFmpeg, while it is not.

Ok - I haven't run into those headers, and I assumed that aes.h wasn't a
public header, since I assumed that the ffmpeg api was supposed to be
format-agnostic. I also assumed that the set of public headers was
sufficiently small, since I assumed that ffmpeg had a sensible policy of
not making everything under the sun public. Only if that's not the case
will the source be polluted 'all over the place'.

My assumptions were based on the fact that writing a format-agnostic
video decoder using ffmpeg and C++ is possible right now without jumping
through hoops...

Regards,

  Uli