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

[D Richard Felker III]

On Fri, Feb 11, 2005 at 02:46:57PM -0600, Zoltan Hidvegi wrote:
> preprocessor macros to implement those.  Templates can also be used to
> write fixed-length loops which are unrolled at compile time instead of
> hoping that a for loop you write will be unrolled by the compiler.
> And templates combined with classes and inheritence (when the base
> class is a template) allow some neat tricks.

unrolling is almost always a horrible idea for performance...

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

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

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

> But all this is not related to this specific rewrite of mplayer.c, I
> did not even look at it.  But I did consider using C++ templates
> before to write some filters for mplayer, and I do think that the
> restricted C++ I described above is a good tool for that which would
> 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...

rich