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

[Christian Stimming]

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.

> > 3. By all means, anyone who thinks about C++ in gnucash, please please
> > have a look in the already existing experimental code in
> > src/optional/gtkmm/gncmm/ !! For example, the C++ version of gnc_numeric
> > is already there, in
> > gncmm/Numeric.hpp. When reading the discussion here, it still seems to me
> > nobody has really looked into how a C++ set of classes of the engine could
> > look like, while optional/gtkmm/gncmm was intentionally done as exactly
> > one
> > example on how this might look like.
> 
> No. That’s backwards. The object of the exercise is to get rid of Glib, not
> to wrap it. Sorry, that code isn’t useful.

That's wrong - the code is very much useful. Have you looked at it? Yes, it's 
an example on how to write this in C++ if it should wrap the glib-based 
existing C objects, but the C++ interface in itself demonstrates rather 
clearly the parts that are needed regardless of whether the code uses glib or 
not. I mean, ripping out the glib parts is the smaller problem here - getting 
a C++ class collection right is much more difficult. 

> > And the code already demonstrates the constraints that have to be thought
> > about when talking about C++... such as: Which string type will be used
> > etc. (Think Numeric::to_string() and Numeric::printAmount()) The class
> > gnc::Numeric is probably one of the very few classes where a C++ struct
> > can directly be used as a replacement of the C class. But this is the big
> > exception. All other "important" classes will give us plenty of headaches
> > if there should be a coexistence of C and C++ during a migration path.
> 
> One handles things like which string (or iostream) class is being output
> with templates and type traits.

I am not convinced templates and type traits will easily solve the question on 
what output strings a class such as gnc::Numeric should have.

> > 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.

Regards,

Christian