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

[Michael Niedermayer]

On Sat, Aug 02, 2008 at 06:20:03PM +0200, Diego Biurrun wrote:
> On Sat, Aug 02, 2008 at 05:33:50PM +0200, Michael Niedermayer wrote:
> > 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.
> 
> So far we have Mans, Baptiste and Diego in favor, with only you
> against..

ehh?

mans clearly said he considers common.h and internal.h as exceptions
baptiste said he still has to think about if the #include of
avcodec.h in audioconvert.c should be there or if audioconvert.h is sufficient
And the wanderer clearly said he is against the include every header
in every c and h file directly and redundantly.

So while my proposal of no header includes another header has very
few supporters, the extreem opposite you want has only yourself.

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/ff19a29a/attachment.pgp>