lubuntu-desktop team mailing list archive
Mailing list archive
Re: [Lxde-list] About future development, the use of dbus and C++
On Tue, 2011-10-18 at 13:00 +0800, PCMan wrote:
> I just passed my license exam yesterday. So that means I will have a
> little more free time from now on.
> I'm now thinking about future development.
> Since dbus support is now part of glib and nowadays dbus is widely
> maybe it's time to replace our own hand-made IPC with dbus and make
> use of dbus more in LXDE.
> It's possible to use dbus inside menu-cache and in the session
> PCManFM might also use it for IPC and to provide some interfaces to
> other applications.
On the BIND 10 project, we also decided to switch to D-Bus after looking
at a few alternatives to replace our own custom communication system. We
haven't made the switch yet, so I can't say how much trouble it is. ;)
> The second issue is the use of C++ in LXDE. Currently we mainly use C
> and in the future there might be vala.
> Doing programming in pure C is quite inefficient and error-prone on
> memory management sometimes.
> In C++, things can be better encapsulated if it's used carefully.
> There also exists some very high quality libraries, such as boost and
> some tools provided by google.
> Using C++ inside LXDE only introduces one additional runtime lib,
> So actually I'm considering the possibility of using C++ in PCManFM.
> Implement some new features with C++ will be much easier than doing it
> with pure C.
> With C++, the development can be more rapid and we can utilize many
> nice existing libs.
> Later, I'll try to use C++ inside PCManFM is feasible and will do some
> experiments in git branches.
> Of course, the program should be kept as fast as old versions and
> memory usage cannot significantly increase.
> Otherwise, I won't use it.
We also chose to use C++ when starting BIND 10, and I've been mostly
pleased with the results. Performance is excellent, and the code is
generally safer (smart pointers eliminate most memory or other leaks,
basic data structures are already present in STL or Boost, exceptions
let you handle faults at the appropriate place).
The main problem with C++ is that it is very easy to go a bit crazy with
all of the language. We crossed the line at one point when we had a bit
of template code that only 2 people on the team could understand. So...
manage your complexity carefully if you use C++!
We use Boost, and have not had any real concerns at all. (We are limited
to using the header-only version of Boost, due to licensing issues...
our company is strictly BSD License, but we can still use almost all of
Boost.) It's high-quality, very portable code.
One recommendation is to also compile code with clang. The error
messages are much more readable than g++, and you find a different set
of problems. (Microsoft Visual Studio and Sunstudio both find different
errors, but one runs only on Windows and the other only on Solaris, and
neither is free.)
One final advice is that we use Google Test along with lcov to do unit
tests and also get code coverage reports. Any code without tests is
probably wrong (and most of the code with tests too). :)