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

[Ivan Kalvachev]

On 8/3/08, M?ns Rullg?rd <mans at mansr.com> wrote:
> "Ivan Kalvachev" <ikalvachev at gmail.com> writes:
>
>> On 8/3/08, Michael Niedermayer <michaelni at gmx.at> wrote:
>>> On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
>>>> The Wanderer <inverseparadox at comcast.net> writes:
>>>> 
>>>> > Diego Biurrun wrote:
>>>> >
>>>> >> On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
>>>> >> 
>>>> >>> On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer
>>>> >>> wrote:
>>>> >>> 
>>>> >>>> Would it be possible that you could spell out the rule you think
>>>> >>>> is a rule so we all know beyond doubt if there are exceptions and
>>>> >>>> if so which exactly.
>>>> >>> 
>>>> >>> All files should #include everything they need directly.
>>>> >> 
>>>> >> For system headers like inttypes.h that are documented to always
>>>> >> #include other headers like stdint.h, I consider just inttypes.h
>>>> >> enough.
>>>> >
>>>> > What about for non-system headers which are, or could be, "documented"
>>>> > (that is, explicitly guaranteed) to always include particular other
>>>> > headers - or, more to the point, provide particular symbols?
>>>> 
>>>> Same thing.  Let me try to state exactly what I want the rule to be:
>>>> 
>>>> For each type, symbol, or macro used in a file (source or header),
>>>>   the file shall contain an #include line guaranteed to provide,
>>>>   directly or indirectly, a declaration or definition of the type,
>>>>   symbol, or macro.
>>>> 
>>>> Is this unambiguous enough?
>>>
>>> Yes, thank you!
>>>
>>> I do not want to make a premature statement but i think this suggestion
>>> would be acceptable.
>>> Though it is certainly not what diego suggested nor how i understood
>>> your previous mails.
>>
>> I do not like it.
>>
>> 1. It doesn't allow declaration or definition to be in the same file
>> (source or header) where it is used.
>
> That was obviously not my intention.
>
>> 2. The rule doesn't imply or limit inclusions to the necessary. You
>> can fill headers with useless stuff, without breaking the rule.
>
> You can always fill your files with useless stuff.  
>
>> 3. The "indirect" inclusion is definitely huge step back.
>
> A step back from what?  In what respect?
>
>> 4. There is no need for all headers to be self sustained. I know this
>> is the key to that system, but definition that says "... a file
>> (source or header included by the source)..." would work just as well.
>
> That would be a different rule, and one that I consider inferior,
> because it leads to trouble.  Trust me, I've been there.

I don't see why I should take your 
(or anybodys' else) words only on trust.

Every system have good and bad sides,
each system solves some kind of troubles and causes others.

I'm sure your system works, but as you alone said "That a certain
method can, if enough force is applied, achieve a working end result,
does not in any way whatsoever make it a good method."

The system you are advocating also have bad sides,
you may think they are insignificant,
but other people may not think  so.
We all had some bad experience with headers 
that we don't want to repeat.

I would like you to explain what troubles your system solves,
what troubles it causes, why it is good trade off and 
how much better it is compared to other systems
(at least the ones you've tried).

The check is the highest form of trust.
Enlighten us.