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

[Zoltan Hidvegi]

Luca Barbato wrote:
> Reza Jelveh wrote:
> > i don't know if its been mentioned yet or not... but hell yeah c++ is
> > damn well the wrong tool. have fun with the portability issues of c++.
> Let's add something:
> 
> 1 libstdc++ is a mess, is huge, could not be present in every arch.
> 2 C++ has too much stuff inside and requires a much more in depth 
> knowledge to _start_ write half decent stuff (if you want to write 
> something really good you need to know most of your language, no matter 
> which is)
> 3 C++ is ugly to see if you don't like baroque constructs and so on.
> 4 if you want to move from C to sane C++ you have to rethink/rewrite all 
> your code since you can't use the same approach and have it work at the 
> same speed.
> 5 For points 1..4 few people here _stand_ C++, let alone those who like it.

Sorry to feed the flame, but I'd like to defend C++ a bit, even though
I agree with most of the critics of C++.  My paid job is to write
programs where speed and memory efficiency is extremely critical.  And
I use C++ because it has some features which help me a lot to optimize
my preformance.  But it is certainly not the OO features of C++ which
allow that.  I think the most useful feature of C++ are templates.
You can think of templates as a fancy macro processor, but unlike CPP,
it is a turing-complete language, and bit similar to the lisp macro
processor.  libavcodec uses templates heavily, but it uses ugly
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.

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.

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

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

Zoli