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

[The Wanderer]

Michael Niedermayer wrote:

> On Thu, Jul 31, 2008 at 05:00:40PM -0400, The Wanderer wrote:
> 
>> Michael Niedermayer wrote:

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

But if that other header is not available, compilation would fail
anyway, because the original header needs something which is not
defined.

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

And how is the user to know what to add? In the case of the enum it's
mildly obvious, but exactly how that enum is defined is not obvious, and
finding out how it is defined would require tracking down the header
which defines it - which leads to the same problem as before.

> Or maybe the functionality is available but in a different header ...

That's a more reasonable argument, but how often - especially, given the
context, within a provides-its-own-headers application such as FFmpeg -
does that actually arise?

I acknowledge that it appears to happen fairly frequently when
attempting to include system headers on incompatibly-designed systems,
but that's something of a special case IMO.

> 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 remember seeing this discussed somewhere once, and yes, I agree that
this could be a problem - but I think that I would say that defining
NDEBUG in a public header would be at least as bad a thing as e.g.
printing to stdout in a library; IOW, this would be a bug in the header.

> The rule of including headers in headers is a absolute pain for some
> use cases to deal with.

I don't doubt or seriously dispute that. The alternative (from at least
an end-user tracking-down-the-right-headers perspective) is, however,
IMO significantly worse.

> The advantage of this is purely "because its the right way".

And just why is it that it is the right way?

> The only reason why its not causing a problem is plain because its
> not done,

It certainly is done - extensively in system headers, if nothing else.
(This has indeed caused problems in some cases - longstanding and
recurring "conflicting types" bugs in Debian's kernel headers vs. libc
headers, for instance - but given how few there seem to be vs. how
widespread the headers in question are, I don't think it's an especially
major issue.)

> our headers luckily do in general not include all the headers they
> somehow depend on.

(I think that is my opinion that it is impossible for one header to
depend on another. A header, like any source file, can depend only on a
symbol (or collection of symbols), which can be defined anywhere. That's
more a matter of semantics, though.)

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

Perhaps a few, but Uoti has made a few which seem sensible to me
(although also at least one which does not). The fact that Uoti appears
to agree with me is enough to lead me to doubt my own position, but I'm
not giving up on it yet. ^_^

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.