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

[Michael Niedermayer]

On Fri, Aug 01, 2008 at 09:20:46PM -0400, The Wanderer wrote:
> Michael Niedermayer wrote:
> 
> > On Fri, Aug 01, 2008 at 05:18:18PM -0400, The Wanderer wrote:
> > 
> >> Michael Niedermayer wrote:
> 
> >>> Theres a difference between
> >>> * every header musts somehow include its dependancies
> >> 
> >> This is what I (currently believe I) am advocating.
> > 
> > and i do not oppose the rule of
> > "every header musts somehow include its dependancies"
> > 
> >>> * every header must directly include its dependancies
> >> 
> >> This is something which I may have supported in the past, and may
> >> support again in the future, but am not presently terribly fond of.
> > 
> > this ("every header must directly include its dependancies") is what
> > i strongly oppose and what started this thread, peter removed a
> > #include "avcodec.h" because it was already included by
> > audioconvert.h and people started flaming about it ...
> 
> 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.
I do not know which is best, but IMO it does not matter, its a bikeshed issue
whichever way is choosen the file will compile fine and in the rather
unlikely case that avcodec.h is removed from audioconvert.h which would
require the enums to be moved to a different header, its really just a 5sec
job to fix the compilation failure of audioconvert.c


> 
> If the first header will inevitably include the second, then including
> the second while also including the first is redundant and
> inappropriate. If the first header may or may not include the second,
> then including both the second and the first is the appropriate thing to
> do.
> 
> For the case of audioconvert.h and avcodec.h, that central question has
> not been answered AFAIK. I held the opinion that the removal made sense,
> because I also held an implicit assumption that audioconvert.h would
> inevitably need avcodec.h. If that is not the case, then I would agree
> that the removal should not have been done.

The question is even more complex than this, because its debateable
in how far audioconvert.c should include avcodec.h at all.

avcodec.h is a big thing for libav Codec, audioconvert is no codec
its a audio sample format converter that just needs avcodec.h because
the sample format enum is in there ...

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

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- 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/c9776ff2/attachment.pgp>