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

[Michael Niedermayer]

On Sat, Aug 02, 2008 at 08:24:27AM -0400, The Wanderer wrote:
> Michael Niedermayer wrote:
> 
> > On Sat, Aug 02, 2008 at 04:09:47AM +0200, Michael Niedermayer wrote:
> > 
> >> On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
> 
> >>> But he removed it from a .c file, not from a header. I suspect I
> >>> believe that the two should not necessarily be treated the same
> >>> way.
> >>> 
> >>> My thoughts on this are (apparently) still evolving, but I think
> >>> the central question here revolves around whether a given header
> >>> file is *guaranteed*, either by documentation (or specification,
> >>> etc.) or as a side effect of its own requirements, to need a
> >>> given other header file - i.e., will audioconvert.h never cease
> >>> to need some symbol from avcodec.h and thus need to include it,
> >>> or may it potentially some day not need any such symbol and
> >>> consequently cease to include that header?
> >> 
> >> currently audioconvert.h needs the audio sample format enum and
> >> audioconvert.c needs it too, and its provided by avcodec.h after a
> >> 5 sec look, audioconvert.c also use av_free() and uint8_t at that
> >> point one can start a long discussion if stdint.h and mem.h should
> >> be included or avcodec.h or nothing or all 3.
> > 
> > after a little longer ;)
> > 
> > it also uses lrintf & snprintf thus also needs one way or another
> > stdio.h and math.h with  _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE
> > defined before inclusion of math.h
> > 
> > so strict direct inclusion rule would require for audioconvert.c (145
> > lines)
> > #include "audioconvert.h" (the prototypes)
> > #include "avcodec.h" (sample format enum)
> 
> Actually, because audioconvert.h needs that same enum, unless I'm 
> misremembering my C these two lines would have to come in the reverse order.

no, audioconvert.h already incldues avcodec.h.
the #include "avcodec.h" does nothing its just because the diego-mans
rule says it should be there.
The whole after all was an example of how it would look if the direct
inclusion rule was followed strictly. And that implicates that all headers
also directly include all their dependancies.


> 
> Furthermore, I would say that because audioconvert.h will need that enum
> for just as long as audioconvert.c does, the include to support the enum
> should be in the header rather than in the .c file. (This means that if

What diego and mans want is that the #include is both, in the c file as
well as the header. Which is what iam opposing so strongly.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080802/87ec7de6/attachment.pgp>