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

[Geert Janssens]

On Saturday 25 January 2014 21:33:07 Christian Stimming wrote:
> Am Donnerstag, 23. Januar 2014, 14:56:26 schrieb John Ralls:
> > > 2. If we decide to switch to C++ at this point in time, by all
> > > means we should choose C++11. Things like the auto keyword and
> > > the standarized things which no longer require boost will make
> > > life so much easier in many places.
> > 
> > I agree, but I’m concerned that it will prevent building on any but
> > the latest systems, and may even limit the systems we can build
> > *for*.
> This statement is true for the "building on" system (the host and
> build system for a cross compiler), but fortunately surely not true
> for the "build for" system (the target system of a cross compiler):
> gcc supports the majority of C++11 with 4.6 and almost everything
> with 4.8. The target systems are no fewer than what normal gcc/C++
> can target. As for the build system, yes, that limits our build
> system choices right now.
> 
Our windows build currently runs gcc 4.5.2, which is obviously too old. But I have a local branch 
in which I overhauled the complete build system. That branch is using gcc 4.8. With some help 
from Gary Bilkus that branch is now compiling and running. The only part left is to update the 
dist scripts to make an installer based on some updated package locations.

So the Windows platform won't be a problem here IMO.

<snip>
> > > Also, pimpl in itself isn't of much value per se for an
> > > application
> > > project
> > > such as gnucash. The picture is different if we're talking about a
> > > library,
> > > but gnucash is an application. For an application project, IMHO it
> > > is
> > > usually enough to keep the member variables private, hence guiding
> > > the developers to use only the public interface of the class.
> > > Pimpl OTOH would just confirm this access levels in a much
> > > stricter way. But as we're inside our own application code
> > > anyway, IMHO using pimpl in itself isn't as important as it would
> > > be for a library, and mainly a matter of taste.
> > 
> > No, the point of PImpl isn’t to enforce privacy, though it does do a
> > good job of that. It’s to isolate recompilation so that making a
> > change to a class declaration like adding a new member variable
> > doesn’t telegraph through to the exported header and require
> > recompiling everything.
> Yes, I agree Pimpl is very good in isolating recompilation. I just
> think this isn't as important for an application as it is for a
> library project. And recompilation times for an application also
> don't matter as much as they used to do.
Actually I would very much like to see the engine become a true self-contained library.

It would open up possibilities that are more difficult to achieve now.

I think for example of the recent thread on the list by someone who wanted to install gnucash 
on a server to have access to its python bindings. In such environment a library is sufficient 
and the gui is overhead.

Another one - on the destkop we will probably always only have one gui (based on one of Gtk, 
Qt, wxWidgets,...). But that interface would never be portable to Android or iOS. Getting 
something done on these platforms will also be easier if we'd have a self-contained portable 
library to start from.

It might even make interaction with other accounting software possible. That would be mostly 
to the benefit of the other software but we're not proprietary software trying to lock in users so 
that would still be a good thing.

I'm not saying any of this is going to happen any time soon, but I prefer to keep my options 
open. Personally I'm most interested in being able to provide a decent solution on Android/iOS 
because it surely looks like tablets and smartphones will become dominant computing devices 
for ordinary users in the future.

Geert