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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
