[FFmpeg-devel] Moving if(constant expression) to preprocessor?

[Luca Barbato]

On 09/20/2010 12:02 AM, Axel Holzinger wrote:
> I tried hard, rally, but I don't see the parallel.

We do.

> Because optimised code doesn't reflect anymore the original C code.

...

> Come on, why do you use -O1 and not -O3 if optimisation isn't an issue
> in debug builds?

you can use -g with -O3 and it remains helpful...

> This discussion is ridiculous. You are using -O1 to get help by the
> optimiser to throw away code that anyhow wouldn't work. This might be
> convenient, you don't have to write stubs. But it's still a hack.

and works quite fine with a LARGE number of compilers...

>>> Every now and then in FFmpeg user or libav user I read "Look at
> the 
>>> code". I want to look at the code while it does process my 
>>> calls. So I  want to debug and I don't want to be hindered by
> optimised 
>>> away local variables, loops, etc.
>>
>> printf is your friend.
> 
> Some debuggers are your friend sometimes (okay, maybe not gdb ;-)

gdb is wonderful.

> Come on, use printf, if you like, but don't use this as an argumnt for
> not supporting clean unoptimised debug builds. printf works also in
> release builds.

added value in using printf (just don't if you have to debug threaded code)

> Fair enough, so where do you draw the line here? Having one to one
> compiled assembler code fitting the C code also simplifies debugging
> (there's not only runtime critical issues). I still can't understand
> how you can weigh the cost of four additional super simple macros so
> heavy while having optimiser free debug builds so light. FFmpeg/libav
> is a framework, there might be a thousand different forms of using,
> developing with it, not only yours. How much something helps somebody
> might not always be clear to you. How much addtional macros cost is.
> And again, it's no hackish special case macros, it's totally generic
> straight forward macros.

Do try yourself. have fun spending few hours doing that, see how it
doesn't change anything, enjoy when it breaks.

>>>>> Using a const expression in a runtime if is obfuscation
>>>>
>>>> Code is obfuscated when it is not obvious at a glance what it
> does.
>>>> If you find it hard to understand what
>>>>    if (CONFIG_FOO) do_something();
>>>> does, you should probably consider a career not involving 
>> programming.
>>>
>>> You are referring to how the code WORKS. That is indeed 
>> obvious - and 
>>> as well obvious with "AV_IF" instead of "if". I'm referring 
>> to how the 
>>> code BUILDS - and that is NOT obvious with "if" and the 
>> dependency on 
>>> dead code elimination. It's not even documented in the code.
>>
>> It is non-obvious to most people how just about any construct 
>> is turned into machine code, yet they have no trouble 
>> understanding the source.
> 
> And you think these people are getting help by optimised debug builds?

processed macros get lost once you build the code, then you have _quite_
a problem tracking what was what.

> That's not the point. It's not about optimisation. The hack is that a
> compiler feature - in this case dead code elimination - is relied on
> to make the build succeed. An optimisation does not - or should not -
> affect the meaning of the code. Here it does. That was my point.

all they do in a way or another...

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero