Le tridi 23 brumaire, an CCXXV, James Almer a écrit : > I don't really like this method. This kind of ifdeffery is very > uncommon and feels dirty. Just look at avutil/common.h to see how bad > a public header can get this way. > I'd prefer if we can stick with the usual internal opaque structs > instead.
What is the exact solution you would propose instead? Please give a thought to the drawbacks of any alternative solution compared to this one, including indirection overhead. > The plan was to remove as many internal-but-not-really fields across > the codebase as possible on the next major bump. Ideally, we'd be > consistent with whatever method we choose to achieve this, and opaque > structs are already being used everywhere, including avfilter.h Almost everything in AVFilterLink is internal, but it is still needed there, it can not be removed. I think you are confusing with per-codec fields: fields that serve only for a few codecs are moved in private structures. But fields that are common to most codecs stay in the context. To hide private fields from the public API is a different issue altogether. There are several ways of doing that, the one I used was the one I found that minimizes first overhead, then brittleness, then ugliness. But I am open to other suggestions. > In any case, this is missing the usual header guards. This is intentional: this is not a normal header, it should not be included the normal way, and in particular never twice. The absence of guards is meant as a hint in that direction. > This shouldn't happen. Guess it's because of the missing guards? I do not mind adding the guards to avoid that, if that it what people prefer. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
