Gente C++ification

[Stefan Westerfeld <stefan space twc de>]

   Hi!

When I first saw BEAST, my reaction was: its a great piece of software, but it
should have been written in C++. There were reasons at the time Tim started to
work on BEAST not to use C++. There was no toolkit that was written in C++,
freely available (under the conditions of the LGPL) that was written in C++.
Free compilers, like gcc, had still problems supporting C++ fully and
correctly. So by choosing Gtk+ and by using GObject, an object oriented
implementation of BEAST was possible, while still using C.

However, times have changed. Meanwhile gcc does a very good job on C++ code.
The existence of large open source projects using C++ (like Ardour, LMMS, Qt,
KDE, OpenOffice) shows that C++ works very well as primary language for
developing free software.  There are C++ wrappers to Gtk+ which work reasonably
well, but then, the toolkit is still written in C. Tims work on Rapicorn is an
attempt to provide a pure C++ toolkit, which could one day be used by BEAST.

So I suggest that BEAST should fully switch to C++ now. However, we need to
ensure that the code base is kept working. I don't think that we can afford to
port libbse to C++ in one step, because it would take too long. Therefore my
proposal is to slowly adapt everything to C++, and my new merge requests will,
if possible, always change the bits and pieces I work on to C++.

BEAST needs datastructures (like a datastructure to store events in, to be used
for events in a part) that have a nice C++ interfaces. The plugins need to be
ported to C++ (which should be easy). Basically for every C idiom or algorithm,
a suitable replacement should be written, in C++.

I suggest to port everything incrementally, so that at all times, BEAST works,
but with every porting change, it works a bit more like the C++ project it
should finally be. So some temporary inconvenience needs to be accepted: for
instance one may port bsepart.c to bsepart.cc, but the interface to bsepart
will still have C function calls. Especially as long as the glue layer (SFI)
doesn't fully support C++, procedures may still remain plain C, whereas the
actual implementation of the object will be written in C++.

The strategy of gentle C++ification (as I call it), will eventually lead to a
project that is written completely in C++, but temporarily it will result in
mixed C / C++ implementations, where the share of C++ code will grow with every
merge request, until no C code is used at all. While this may mean that during
the porting process code gets touched twice (or more), the good thing is that
we can at all times keep a fully functional BEAST, and that the strategy will
always go in the right direction (a complete C++ code base).

I'll try to create new merge requests towards this goal.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan