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

[Måns Rullgård]

Michael Niedermayer wrote:
> On Fri, Aug 01, 2008 at 02:12:21PM +0100, M?ns Rullg?rd wrote:
>>
>> Michael Niedermayer wrote:
>> > On Fri, Aug 01, 2008 at 09:39:16AM +0100, M?ns Rullg?rd wrote:
>> >> Michael Niedermayer <michaelni at gmx.at> writes:
>> >>
>> >> > The only reason why its not causing a problem is plain because its not
>> >> > done, our headers luckily do in general not include all the headers
>> they
>> >> > somehow depend on.
>> >>
>> >> Actually, *all* our headers #include their dependencies.  That's what
>> >> "make checkheaders" makes sure.
>> >
>> > avcodec.h does not include inttypes or stdint directly but use int64_t
>> > and iam sure it would be easier to find headers missing dependencies
>> > than ones listing all.
>>
>> avcodec.h includes common.h, which does include stdint.h.  As I said,
>
> no, avcodec.h does not directly include common.h
> it includes avutil.h that includes common.h which includes inttypes.h
>
> Its kinda ironic that you know the header inclusion chains we have nowadays
> as well as i aka not at all. (without RTFS of course, anyone can figure it
> out by RTFS ...)

The exact chains are irrelevant, and that's the point.  If every header
provides, in one way or another, everything it requires, there is no
need to be concerned with the exact details.

To further the point, if a header does *not* include its dependencies,
no amount of RTFS will tell you what is needed.

>> common.h is a special case.  Its purpose is to avoid duplicating
>> code that would have to be in practically every file otherwise, and
>> this includes including stdint.h.
>
> its inttypes.h which it does include, be that correct or not but its not
> stdint.h. It certainly could be annoying if stdint is available but inttypes
> is not in some build environment ...

inttypes.h is documented to include stdint.h, and both are required in a
standard system.

>> 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.

Just as an experiment, why don't you delete all #include lines from our
header files, and see how much things break?

> also a quick grep indicates that i have 49 .{c,h} files that contain int64_t
> but not stdint, inttypes nor common.h in libavcodec. Not sure how many
> exceptions ive missed that may be used in the new system as substitutions
> for inttypes.

I never said all our code was perfect, and I'm certain finding more examples
is easy.  That is, however, no excuse for not writing new code properly,
nor is it an argument against the general rule.

-- 
M?ns Rullg?rd
mans at mansr.com