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

[Michael Niedermayer]

On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
> Michael Niedermayer wrote:
> 
> > On Thu, Jul 31, 2008 at 07:47:05PM +0200, Michael Niedermayer wrote:
> > 
> >> On Thu, Jul 31, 2008 at 01:11:14PM -0400, compn wrote:
> 
> >>> is this policy documented somewhere?
> >> 
> >> it has not even been discussed or agreed upon yet ...
> >> 
> >> Besides maybe we can make the converter independant of avcodec.h
> >> Which seems better either way ...
> > 
> > and just to repeat my view on the headers inclusion IMHO headers
> > should NOT include other headers, this nicely avoids such problems
> > ...
> 
> It also leads to the case where including one header leads to needing to
> include another header, which might in turn need another header, et

which is not available and compilation fails.
The user now who just wants to use the part has to hack the headers instead
of adding a 5 line enum before the header that needs it.
Or maybe the functionality is available but in a different header ...

Or the application breaks randomly until the user realized that audioconvert.h
included acodec.h that included common.h that included assert.h and one of
the headers defined NDEBUG thus disabling asserts. and rendering the
user own #include <assert.h> worthless (this one actually happened to me
once with assert and some headers i dont remember ...)

Some more concrete examples
avcodec.h uses int64_t, if it would #include inttypes.h it would be between
unuseable to a PITA in any environment that does not have inttypes.h.
libavcodec may be compiled with gcc + glibc in a gnu environment. but
it might be used in VC++ or another obscure environment that lacks these
headers.

The rule of including headers in headers is a absolute pain for some use
cases to deal with. The advantage of this is purely "because its the right
way".
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.


> cetera. If a header needs something then it should provide that thing,
> either by defining it directly or (more practically) by including
> another header which already defines it. A header which fails to do so
> is, IMO, broken.

Do you have a argument beyond "is broken" vs. "is the right way"?

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20080801/d18a9252/attachment.pgp>