C++ plans? (Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791)

[Christian Stimming]

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 [1] has more-or-less the same
> functionality with I hope less work.

Hi John,

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 
mind?

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 
here?

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.

Regards,

Christian