On Sun, Nov 13, 2016 at 11:54:23PM +0100, Nicolas George wrote: > Le tridi 23 brumaire, an CCXXV, James Almer a écrit : > > AVSomethingInternal *internal; > > > No technical advantages i can think of compared to your method, but it's > > thoroughly tested, clean, and above all ubiquitous. See for example > > AVFilterInternal and AVCodecInternal. > > It has technical DISadvantages, and therefore needs a good reason to > choose. I would really appreciate that objections acknowledge and > discuss them, however minimally. In other words, unless your message > contains a sense that looks like that: > > Compared to yours, my solution has the drawback of <fill in > here>, but I still think it is better because <fill in here>. > > ... I consider that the advice was given without having thought about > all the implications and therefore cannot be really valuable. >
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) So please, I don't want FFmpeg to be again the laughing stock of readability on the Internet just because a structure dereferencing was considered too much overhead. Regards, -- Clément B. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
