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

[Michael Niedermayer]

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

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)
#include <stdio.h> (snprintf)
#include "libavutil/mem.h" (av_free / av_malloc)
#include <stdint.h> (uint8_t)
#define _ISOC99_SOURCE
#include <math.h> (lrintf)

and the time finding this list took likely longer than all include bugfixes
this file will ever need ...

and id like to call attention to the fact that this is a 145 line file, i dont
want to know how many includes would be needed for a 10 times larger file. If
this system is applied

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

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/2e3f5962/attachment.pgp>