[FFmpeg-devel] [PATCH] doc/examples/muxing: make compatible with C++

[Don Moir]

----- Original Message ----- 
From: "Stefano Sabatini" <stefasab at gmail.com>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Thursday, March 20, 2014 6:42 AM
Subject: Re: [FFmpeg-devel] [PATCH] doc/examples/muxing: make compatible with C++


> On date Wednesday 2014-03-19 19:21:36 +0530, Anshul encoded:
>> 
>> 
>> Michael Niedermayer <michaelni at gmx.at> wrote:
> [...]
>> >so to summarize we have
>> >
>> >A. add ~6 lines of code to each example to make it C++ compatible
>> >B. add seperate C++ examples
>> >C. add patches that get applied by makefile to create c++ examples
>> >D. add a description to the wiki/faq/whatever on how to make the
>> >   examples C++ compatible
>> >
>> >Iam happy with any solution if theres a consensus, that is if the
>> >people in this thread, including Anshul agree.
>> >
>> >In absence of a consensus, anyone can volunteer to maintain C++
>> >examples and its then his/her decission on how to maintain them,
>> >that is in git as seperate files or on the wiki or as patches.
>> >
>> >I think its better if a consensus is found though, but i dont know
>> >if thats possible, peoples oppinion seem far appart
>> >
>> >[...]
>> 
>> I agree with B, in that way we can add example in most other language.
> 
>> It would be easy to write an seprate example for python, php or gimp
>> scripts. Rather option A and C does not look possible for python and
>> PHP.
> 
> How do you plan to add examples for python/php/gimp? As far as I know,
> we don't support those languages directly.
> 
>> 
>> Option D is good for maintenance prospect's but user are more happy
>> with example. I think thats why linux developer's add examples with
>> most trivial system call.
>> 
>> I am happy to maintain those examples.
> 
> I'm for option D. Users will have to adapt the examples to their own
> environment, also documenting the required conversions will be useful.
> Providing a C++ example using a C++ toolkit seems a good option.
> 
> I don't think maintaining duplicated code for C/C++ is a good idea as
> I don't want to keep in synch C and C++ code, maintaining C examples
> alone is enough work already, and we will end up with unsynched code
> (C and C++ versions working differently).
> 
> Option A could be also be acceptable, but in the end we will need to
> add more than 6 lines (for example for supporting C constructs not
> supported in C++), and that will increase examples complexity even
> more.
> -- 

You just need clean, readable, well documented C examples.