C++ plans? (Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791)
christian at cstimming.de
Tue Jan 21 16:04:59 EST 2014
Am Samstag, 18. Januar 2014, 19:20:45 schrieb John Ralls:
> > Thanks for fixing the bug!
> > Note that the functions for using the GDate are still relatively new in
> > gnucash. That's why in most cases they are not (yet) being used, even
> > though they are more suitable and less error-prone and better altogether
> > :-)
> And one of the GLib dependencies that we're getting rid of. ;-)
> No worries, though: Boost::gregorian  has more-or-less the same
> functionality with I hope less work.
well, I know boost quite well and I fully agree that date handling is just one
more example where boost as a very good and long lasting solution.
boost::gregorian for the date, boost::posix_time::ptime for date-and-time
points in time, and boost::posix_time::time_duration for differences of date-
and-time, and so on. If you're writing some backend code that is in C++ and is
allowed to depend on boost, by all means the date and date-and-time types
should be taken from there.
However, that brings up my actual question: What are your plans for C++ and
boost inside gnucash? Is there any sort of migration plan that you have in
If the choice were there, I would definitely prefer C++ code over C. However,
that still doesn't solve the toolkit questions: C++ with boost, yes, but what
GUI? If you want C++ with Qt but still use boost, you've already opened the
first set of conflicts (e.g. boost::gregorian vs. QDate and QDateTime; boost
is much better, but the qt types are needed for interfacing with the qt
widgets). That is just one out of several questions.
Under the assumption you already have good proposals for this, I have the next
question: What is the migration plan for the gnucash codebase? The unittests
cover the current functionality including all its weird and nasty C quirks.
When rewriting the engine types as C++ classes, the existing unittests by
nature will cover only a smaller part of the new code, so this won't relieve
us much here. And a backend C++ class can't be a complete drop-in replacement
for an existing C/gobject "object", so we probably can't use the existing GUI
code and step by step replace the engine types with C++. What's your idea
To make the picture complete, a few years back I took the try to add C++
wrapper classes on top of the existing gobject classes using glib's C++
wrapper. The code is in src/optional/gtkmm, and it is being compiled both by
--enable-gtkmm and also the cmake project "cutecash". In the cutecash
experiment, the wrapper classes were working fine... however they clearly look
just like wrappers and still keep their old C gobject pointer around, which is
also needed sometimes. The code doesn't look elegant as long as it's still
only a wrapper. However, this step enables writing GUI code in C++ while still
using the existing engine code. Unfortunately, the more interesting GUI stuff
can't be done as long as the wrappers are gobject thingies. I tried to look
into implementing a GListView derivative in C++, but gave up because of the
impermeable gtkmm and gtk stuff :-( However, the Qt implementation of the list
view works quite well in cutecash.
More information about the gnucash-devel