Gnucash c++

Mike Alexander mta at
Tue Aug 12 08:43:51 EDT 2014

On Aug 11, 2014, at 4:52 PM, Christian Stimming <christian at> wrote:

> thanks for investing time in Gnucash and also in its development towards more 
> future-proof programming technologies. I was a bit puzzled about the benefit 
> of switching the "normal compiling" from C to C++, just by itself. IMHO, there 
> is of course an immediate benefit if the data structures move from plain C 
> structs to C++ classes, with constructor/destructor and such. If you plan to 
> do such a transition with any of gnucash's data structures, of course every 
> code using those will have to be C++. However, just changing this into C++ 
> doesn't also solve the problem here: The usage of the C structs in the code is 
> just that: C structs, with foo_new() and foo_delete() functions and maybe even 
> glib's reference counting. To really use C++ classes instead, every single 
> usage of those old C idioms will have to be replaced by proper C++ constructs. 
> IMHO, "just" switching the C compiling to C++ doesn't quite bring you much 
> gain here. Do you think it helps you much? I have some doubts. I see some more 
> benefit when changing individual data structures to C++, then switching the 
> old C functions into wrappers that make the new C++ behaviour available to the 
> C side. This means the existing C code can continue to compile in C, and the 
> next steps would rather be to open the possibility for new C++ code such as 
> unittests and maybe new GUI code in C++ (or python or something similar). IMHO 
> this would be more benefitial. What do others think?

What you say is correct, of course, but I don’t think it’s a complete waste of time to switch over to C++ for most compiles.  It has a few advantages I can think of:

1. C++ compilers enforce more strict standards for C code and will catch problems the C compiler may not catch.

2. When some data structure is converted to a C++ class then there’s a good chance that any code that uses it will already be C++ code.

3. Header files won’t have to have as many #ifdef __cplusplus ... endif constructs.

These are all pretty minor, but they are useful, I think.  There are probably other advantages too.  On the other hand it will be a lot of work to get everything to work in C++.  I think only the easy part has been done so far.  The last time I worked on something like this we did what you suggest, Christian, and it worked well.  Whether it’s worth doing this is not obvious to me.


More information about the gnucash-devel mailing list