C++ and derived classes issue

Geert Janssens geert.gnucash at kobaltwit.be
Fri Feb 12 16:09:33 EST 2016


While working to convert the csv importer to c++ I've come across this issue:

At some point the importer code wants to keep track of a set of values that can be used to 
create a transaction from. The transactions can't be created immediately in that part of the 
code because user manipulations in the GUI can change the interpretation of these values.

The c code used a glist to keep a list of these values (or "properties), each value being 
encapsulated in a struct that also keeps some meta information.

For reference the old code starts here:

To avoid code duplication, I chose to replace the struct with a small hierarchy of classes, the 
base class being GncTransProperty, which handles the common parts and derived classes for 
each type of value that can exist:
* one to keep track of an account (Account *),
* one to keep track of strings (std::string),
* one to store a time value (time64)
* and lastly one to keep an amount (gnc_numeric).

I also chose a generic base class to allow the instances to be stored in a std::vector. Which 
properties get stored will depend on the user choices in the GUI. (I say "will" as that part is not 
set up just yet).

Current attempt of the code is here

Unfortunately this code fails to compile. The error I don't know how to handle is this one:
src/import-export/csv-imp/gnc-trans-props.cpp:232:10: error: 

And similar errors for each specialized class I defined.

I do understand the reason for this error: return type Account * is not the same type as void * 
as in the virtual function in the base class and I explicitly stated I want to override a virtual 
function (as per Meyers Effective Modern C++ recommendation).

What I'm unable to figure out is how to do this properly. The code that will eventually call this 
function will need to get the Account to create a split. It will also need to call a get_value on 
another property to get, say the amount (a gnc_numeric). So depending on the property being 
stored, I need another return type. Or don't I ?

What's a good idiom to encapsulate this information until the point where the differentiation is 
relevant (only when storing a value or retrieving it) ?


More information about the gnucash-devel mailing list