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

[Uoti Urpala]

On Fri, 2008-08-01 at 03:27 +0200, Michael Niedermayer wrote:
> On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
> > 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.

So you think trial and error is a good way to set the dependencies? In
such an inclusion system it is pretty much the only way. And it doesn't
work if some indirect dependencies are conditional or change later.

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

I think defining NDEBUG in a normal header is a bug. That doesn't say
much about the inclusion style in general.

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

It does already include inttypes.h indirectly through libavutil headers.

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

If you create such workaround definitions it's not much more work to
place them in a header named "inttypes.h".

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

There was a thread about this on mplayer-dev-eng not too long ago that
explained much more significant advantages. The main point is that it's
realistic to keep the #include statements in a .c or .h file (mostly) in
sync with what is needed _within that file_; it's not realistic to keep
them in sync with indirect dependencies, at least not without automated
tools that aren't used in practice.

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

I think they include more than you thought (I think pretty much
everything ends up including the <inttypes.h> you talked about above for
example). More like it doesn't cause much of a problem even though it IS
done.

> > 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"?

See above.