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

[John Ralls]

On Jan 25, 2014, at 12:33 PM, Christian Stimming <christian at cstimming.de> 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.

It’s a little more complicated on Macs; the latest GCC is 4.2, and while clang will happily compile C++11, I don’t think gcc-4.2 will and the 10.5 SDK won’t compile with llvm-gcc, never mind clang. I haven’t tested the 10.6 SDK; there was one included in Xcode 4.4 (the one for OSX 10.7) but not 4.6; Xcode 5 doesn’t provide llvm-gcc, and I haven’t tested it with any of the older SDKs.

It might be possible to build gcc-4.8 and compile against the 10.5 SDK, I’ll have to try that.

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

Yes, of course I looked at it. What exactly is useful after you remove all of the wrapper stuff? What even *remains* after you strip all of that stuff? Are you missing that getting rid of Glib means getting rid of GObject as well?

As for the “class collection”, by which I think you mean the overall class design, we’re pretty much stuck with what we’ve got as long as we’re in incremental mode. The same is mostly true of functions, though there are a few that aren’t used and a few more that are just variations which can be consolidated with a little work. 

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

It doesn’t “solve the question”, it makes it easy to provide whatever we need. What we need now is char* in UTF8 to pass to Gtk widgets. If we pick Qt, I guess we’ll need QStrings. Using templates lets the compiler pick which implementation is appropriate with a minimum of effort on our part.

 
Regards,
John Ralls