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

[Axel Holzinger]

M?ns Rullg?rd wrote:
> "Axel Holzinger" <aholzinger at gmx.de> writes:
> 
> > Hi Bobby,
> > Bobby Bingham wrote:
> >> On Sat, 18 Sep 2010 18:00:40 +0200
> >> "Axel Holzinger" <aholzinger at gmx.de> wrote:
> >> 
> >> > Hi M?ns and all,
> >> > 
> >> > M?ns Rullg?rd wrote:
> >> > > "Axel Holzinger" <aholzinger at gmx.de> writes:
> >> > > 
> >> > > > Hi all,
> >> > > >
> >> > > > if compiling FFmpeg code with zero optimisations 
> (even without 
> >> > > > dead code elimination) there are linker errors (undefined 
> >> > > > references to
> >> > 
> >> > > > functions or structs) that come from constructs like 
> i.e. the 
> >> > > > following in libavcodec/allcodecs.c:
> >> > > >
> >> > > > if(CONFIG_##X##_HWACCEL) av_register_hwaccel(&x##_hwaccel);
}
> >> > > >
> >> > > > The runtime (lower case) "if" leads to an undefined 
> reference, 
> >> > > > because it is evaluated at runtime and not at compile time.
> >> > > >
> >> > > > If dead code eliminitation optimisation is on, this isn't
an 
> >> > > > issue, but with optimisations completely off it is.
> >> > > 
> >> > > Don't do that then.
> >> > 
> >> > Hehe, if we all would be so shy, we would still live in caves, 
> >> > wouldn't we :-)
> >> > 
> >> 
> >> Why do you want to compile without dead code elimination?
> >
> > I don't want to compile without dead code elimination.
> > I want to compile witout optimisation.
> 
> Why?
> 
> > Why shouldn't I?
> 
> Because without optimisation, the code will be unusably slow.

Use the release build then. You get optimisation, which you like and
full speed. Let me have zero optimisation and easy debugging.

> > The solution I have presented is adding a couple of macros,
nothing 
> > else. No code, just macros, with the benefit of being able to 
> > conditionally include/exclude code. A very nice and handy feature,

> > useful for all kinds of things. As you can see in the post before,

> > even valid to beu used inside macros.
> >
> >> I don't see what the benefit is.
> >
> > Just one example, debugging unoptimised code.
> 
> Why would you want to debug unoptimised code?

Because I like to understand what's going on inside FFmpeg?

That would be a fair reason, wouldn't it?

> > What is the benefit of optimisation in a debug build?
> 
> What is the benefit of debugging code you do not intend to use?

To understand the architecture.
To understand why a special function call fails.
To understand why another works correct.

Need more?

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.

And still I don't see what is the advantage of an optimised debug
build. What the hell is the debug build good for anyhow then?

> >> And without a compelling reason, I don't think it's worth
> >
> > Do you restrict yourself without a compelling reason?
> 
> I could ask you the same question.

No, I don't.

> >> obfuscating the code.
> >
> > The codes is NOT obfuscated. Where do you get this impression
from.
> 
> It took you several attempts to produce something that 
> appears to be syntactically correct, and even then it takes a 
> while to trace through the macros to see what it does.  That 
> is obfuscated.
> 
> > 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. 

> > and besides it's plain bad style.
> 
> Matter of opinion.  You have made yours clear, as have we 
> ours.  We happen be the ones making the rules here, not you.

Halleluja. God has spoken.

> > Relying on dead code elimination for making a build succeed 
> is a hack.
> 
> Is relying on the optimisation to make the code fast enough 
> also a hack?

No.

Axel