C++ binding

[Simon McVittie]

On 03/02/14 07:35, Karoline Haus wrote:
> Hi I'm looking for a dbus C++ binding. I'm not too keen on using QT (I'm
> running a quite minimalistic system where I don't want to install QT)
> and gdbus is plain C only (as far as I understand)

I'd recommend one of those anyway: they're the most actively-maintained
high-level APIs for D-Bus. For many purposes, I would also recommend
using either GLib or Qt anyway, even if you're not using D-Bus - their
purpose is basically "make application programming not be terrible".

If you're using D-Bus "conventionally" (as an async message-passing
system), you will need some sort of event-loop implementation. libdbus
goes through various contortions to try to support every event loop
while not depending on any of them, which is one of its biggest
structural problems. I'm not sure whether any of the C++ bindings
matching /dbus-c([px+])\1/ address that. In contrast, QtDBus can assume
you are using the Qt event loop, and GDBus can assume you are either
using the GLib event loop or making blocking calls (either way, it uses
the GLib event loop internally, in a worker thread). Focusing on one
particular event loop implementation is a significant simplification and
means they can work with some level of reliability.

GDBus is part of GLib, which has a C++ wrapper (glibmm) if you like that
sort of thing.

The other actively-maintained native-code options are libdbus, which is
plain C and more like a low-level API, and libsystemd-bus, which is
Linux-specific, plain C, relatively new, and I would guess closer to
libdbus than GDBus in terms of how high-level it is.

> I have seen that there is a
> dbus-cxx and a dbus-c++ binding

dbus-cxx seems to be the least dead; it had a release last September.
dbus-c++'s Sourceforge page says "Last update: 2012-10-03" which doesn't
sound good to me. There's also dbus-cpp, which is thoroughly dead; don't
use that one. I would warn you that if you rely on any of these "pure
C++" bindings, you are likely to have to become its de facto upstream
maintainer at some point.

The problem with writing a "pure C" implementation of anything,
particularly a portable one, is that you end up reinventing so many
wheels that you give up in frustration - popular candidates for
reinvention include basic data structures, event loops, portable
wrappers for OS-specific things (I/O, networking, threads), and
object-orientation. By avoiding relying on any existing "platform"
(GLib, Qt, etc.) it's common to end up writing your own platform, which
is usually not as good as GLib or Qt. For instance, Upstart's "platform"
library is the self-deprecatingly-named "libnih".

C++ is somewhat better off than C because it has object-orientation
already, and the STL is larger in scope than the ISO C standard library,
so it already covers some common data structures and some level of
portability; but at that point the STL is essentially acting as another
"platform", and you still need an event loop. Perhaps Boost.Asio solves
that, but at that point you don't have "a pure C++ application
framework", you have Boost.Asio, and I assume that if you'd wanted that,
you'd have asked for it?

I suspect it would be entirely possible to write a good Boost-based
libdbus binding or D-Bus reimplementation, but as far as I'm aware,
nobody has done it.

    S