[FFmpeg-cvslog] r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h

Robert Swain robert.swain
Fri Aug 1 20:30:04 CEST 2008


2008/8/1 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Aug 01, 2008 at 04:37:46PM +0200, Michael Niedermayer wrote:
>> On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
> [...]
>> > Now please stop trolling, and get back to coding, which you do very well.
>> > Quite frankly though, I doubt you have the experience necessary to for
>> > an informed opinion on organisational matters like these.  That a certain
>>
>> maybe. I do not claim to be an expert in header inclusion rules and do not
>> claim to have reviewed dozends of projects what they do and what problems
>> it causes. I just see how well it "works" here, and how little the claims
>> match reality.
>
> Also, its interresting to note that the "all files must directly include their
> dependancies" rule is a rather recent thing in relation to ffmpeg. ffmpeg has
> existed MUCH longer than it, and it has never been a problem for _us_ so one
> has to ask what exactly did this rule fix that caused problems before?
>
> Hyphothetical claims have been given but these have never actually occured
> prior to this rule in ffmpeg.
> While now after the rule developers are being asked to follow it if they do
> not, that undoubtly costs extra time. Its not as if the code works better
> or worse if indirect inclusion is used compared to direct.
>
> But having to deal with the question "which headers do i need" is much
> easier based on a "the ones that contain the things in the error and
> warning messages" than "the ones listed in the standard for every function
> enum, struct, ... used in the current file"
>
> What iam saying is that the rule of direct inclusion is not practically
> doable plain because there is no automatic way that tells one what is
> missing when it is already available indirectly.
> Considering this i think its unfair to pick people out and flame them
> for breaking that rule. Do you always know (without checking the specs)
> which header is needed for every function? I do not, so how should i or
> anyone else add the correct headers when all prototypes are already
> available indirectly so there are no warnings or anything at all that
> would hint at what is missing?

I'm not sure what context to use but the above seemed somewhat
relevant to what I thought of as a seemingly significant pro for
putting includes in headers for their dependencies - if a header's
dependencies change, all files that include that header have to add
the new dependency. This seems a bit annoying to me.

Rob



More information about the ffmpeg-cvslog mailing list