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

[The Wanderer]

Michael Niedermayer wrote:

> On Fri, Aug 01, 2008 at 06:58:42AM -0400, The Wanderer wrote:
> 
>> Michael Niedermayer wrote:

>>> The advantage of this is purely "because its the right way".
>> 
>> And just why is it that it is the right way?
> 
> You said "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."
> 
> I felt that this was an argument based on "because it should be done
> that way"

You may be right about that.

I do believe that there are underlying reasons *why* it "should be done
that way", but I do not have them ready to hand for immediate
explanation. If I have time, I will think about it and see if I can
explain my subconscious reasoning.

>>> 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 thing that really annoys me is that we ended up with some
> developers trying to enforce a rule of "every file includes all its
> dependancies directly"

For the record, that is not what I am advocating; indeed, I believe I
would oppose it. (If taken literally, it would require e.g. that every
file which includes stdio.h also include the things which are needed by
but not defined directly in stdio.h...)

What I am saying is that adding a single '#include "file.h"' should
never result in *new* undefined symbols (barring things like
incompatible header/source versions, of course). I do not think that
this is an unreasonable thing to expect.


I do admit that there are very likely problems which could, perhaps
would, result from the obvious way to ensure that that does not happen
(that way being to have headers include other headers).

I do not think that they are likely to be as widespread or as severe as
you seem to think. This is based, at least in part, on the fact that
this approach appears to be used, without apparent severe problems, in
the near-universally-used headers of e.g. the kernel and the C library.

I also do not think that they are likely to be any more widespread or
severe than the problems which could, perhaps would, result from the
alternate (opposite?) approach of requiring every source file to include
every header it needs, or from most possible neither-nor compromises.

> Theres a difference between
> * every header musts somehow include its dependancies

This is what I (currently believe I) am advocating.

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

> * no header should include any other header

This implies "every source file should directly include every header
file it needs", and I am not in favor of it at all. In theory, if
followed universally, it could perhaps work; however, A) as I believe
others have mentioned, it leads to bitrot includes when formerly-needed
symbols cease to be needed but the fact that a particular header is
unnecessary goes unnoticed, and B) since many widely-used headers (at
the very least, glibc and the Linux kernel) do not do this, it is not
and cannot be arbitrarily made to be followed universally.

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