Business objects cpp

[christopherlam]

No description provided.

[christopherlam]

some .c were using 0 which didn't map to a valid enum. I've modified behaviour slightly to avoid them.

EDIT: they're causing PERR messages in a regular datafile.

[jralls]

There's nothing technically wrong here, but it has a lipstick-on-a-pig feel to it. The only thing you're changing to C++ is using std::optional to replace a boolean value pair. What's your ultimate goal?

[jralls]

As long as you increment by 1 you need only assign the first one, and 0 is the default so you can just add the 0 enum and skip the initializer, e.g.

typedef enum
{
    GNC_PAYMENT_NONE,
    GNC_PAYMENT_CASH,
    GNC_PAYMENT_CARD
} GncEntryPaymentType;

[jralls]

Those are remarkably useless comments.

[christopherlam]

Main goal is to benefit from C++ stricter type checking etc.

[jralls]

Main goal is to benefit from C++ stricter type checking etc.

I don't think you can do that incrementally: Polymorphism in both GObject and QOFObject depends on passing and casting void* and that's fundamentally incompatible with C++ types. A bottom-up approach, meaning a fresh implementation beginning with C++ polymorphism, either run-time via derived classes or compile-time via std::variant, is much more likely to succeed. That's not too hard for the GObject side. You'll have to provide some C wrappers for the GUI to use. The real obstacle is QOFQuery. We want to get rid of it and use SQL instead so rewriting it in C++ would be wasted effort.

[christopherlam]

I think there's some benefit to incrementally converting more files to c++ -- it means the next milestone can be "all of libgnucash is now c++". It means more the headers can be .hpp and have less ifdef __cplusplus clutter...

[jralls]

it means the next milestone can be "all of libgnucash is now c++".

No, there's a huge yawning chasm between "compiles with the C++ compiler" and "is C++". The goal is emphatically not to get libgnucash to compile with the C++ compiler. There's no real benefit to that. There's some benefit to rewriting functions to use C++ std algorithms and using STL containers instead of GLib ones, but even that doesn't really help solve our main problems of memory management errors and spaghetti code. Plus those algorithms and containers work much better when they're used with real C++ objects.

It means more the headers can be .hpp and have less ifdef __cplusplus clutter...

That requires the consumer code also to compile with the C++ compiler: Swig files, Gui files, import-export files. That's a lot of extra work that can be made less by reducing the API and pushing the specialization out to the user that needs it.