[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

Clément Bœsch u at pkh.me
Mon Nov 14 14:26:48 EET 2016


On Mon, Nov 14, 2016 at 01:06:30PM +0100, Nicolas George wrote:
> Le quartidi 24 brumaire, an CCXXV, Clement Boesch a écrit :
> > The pros for an internal fields are, for me:
> > 
> > - consistency across the codebase
> > - definitions more readable (if you're advocating the fact that a
> >   multiline define is as readable I'll stop reading right now)
> > - common C pattern, accessible to other developers
> > - tools will likely like it more (doxygen, looking up a field within your
> >   IDE/editor, GDB, or any other tool really)
> > - we can still embed various ifdefery in the structure (for FF_API
> >   ifdefery, or simply defining constants above a field)
> 
> I do not disagree with all that. But you are speaking of the readability
> of the structure definition, which is rather minor.
> 
> Your forget another much more important point : with the indirection,
> the CODE that USES the structure becomes much less readable.
> 

I don't see how. You add a pointer at the beginning of your function
pointing on that internal structure and use that.

> Making the structure definition a little less readable to make the
> actual code a lot simpler, I say it is a very interesting compromise.
> Code needs readability more than definitions.
> 
> I can propose another approach to avoid the indirection but address a
> few of your points :
> 
> struct AVFilterLink {
>     int public1;
>     int public2;
>     ...
> #ifdef FF_PRIVATE_FIELDS
>     int private1;
>     int private2;
>     ...
> #endif
> };
> 
> In particular, I think it will work perfectly fine with Doxygen, IDEs,
> etc.
> 

That might not prevent tools from wrongly detecting ABI breakage from
headers. The best way to have private fields is to make them private for
real, so I would still prefer an opaque pointer, "leaking" zero
information.

> > So please, I don't want FFmpeg to be again the laughing stock of
> > readability on the Internet
> 
> Please keep the emotional arguments out of it.
> 

It's not an emotional argument, it's a political one. "look at the shit
FFmpeg developers still do" does not help the project from getting
contributors/contributions.

-- 
Clément B.


More information about the ffmpeg-devel mailing list