[MPlayer-dev-eng] c++ version of mplayer.c

[Zoltan Hidvegi]

D Richard Felker III wrote:
> unrolling is almost always a horrible idea for performance...

As you say, almost always.  And what you are talking about is blind
unrolling by the compiler.  The problem is that you do want to unroll
some loops, when the bounds are constant and not too big, which would
make the loop variable constant, which then enables more optimization.
But in C you cannot write an unrolled loop without duplication or ugly
CPP hacks.  C++ is not much better, but at least you can do it using
recursive templates.  But I agree, it is not too often you need that.

> > If you know what you are doing, the result will be as efficient as C,
> > but it can be even better, because it allows you to fully inline and
> > expand things which you would have done with loops or functions in C.
> 
> you can do all the same things in c. saying otherwise is deceptive.

You can do a lot of things with CPP, but its ugly and hard to
maintain.  C does not have a turing-complete preprocessor, I'm sure
you agree with that.

> > But it is true that libstdc++ is horrible, and creates a mess of
> > dependency problems.  So in the C++ programs I have, I do not use any
> > STL classes, and I do not use exceptions (although exceptions can help
> > sometimes to make faster and cleaner code), dynamic casts, RTTI,
> 
> false, long jumps can do just as well.

Agreed, although I did not really claim that C does not support this,
and I am not advocating the use of exceptions, actually I am doing the
opposite.

> > globally constructed objects etc.  I compile the C++ programs with
> > -fno-exceptions -fno-rtti, and link them with gcc (not g++), so the
> > final binary has no dependency on libstdc++ at all.  The result looks
> > just like a C binary, does not have the file-size bloat of STL C++
> > code, and has no shared library dependency problems.
> 
> this is a good idea but doesn't change the fact that c++ is a bad
> language.

I agree with you in general, but I still maintain that C++ have some
useful features.  You can think of C++ as a fancy preprocessor for C.
The biggest problem with C++ is that it gives you too much power to
screw yourself.  It hides the complexity of coplicated things, which
makes it very easy to write bad programs.  But that does have some
convinient features, and you *can* write efficient C++ programs if you
are careful and really understand what the compiler will do with the
code you write.

> > not cause much portability burden as long as we can assume that people
> > are using g++.
> 
> bad assumption. we want to eliminate gcc eventually since it sucks...

Actually, this also works with other C++ compilers, as long as you
figure out how to invoke them and how to pass options equivalent to
-fno-exceptions and -fno-rtti.  And if you say the long-term goal is
to eliminate gcc, maybe, but I do not see any other alternative even
planned at this point.  I do not think gcc is that bad, and AFAIK no
other compiler provides powerful inline assembly features similar to
gcc.  I guess the intel compiler has some assembly features, but I do
not think that your planned gcc replacement is going to be the Intel
compiler.

Zoli