[GNC-dev] Starting to work on C++ conversion in xml backend?

[Glenn Serre]

Good afternoon,

On Mon, Nov 2, 2020 at 11:56 AM John Ralls <jralls at ceridwen.us> wrote:
>
>
>
> > On Nov 2, 2020, at 9:22 AM, Glenn Serre <gaserre at spiresoftware.com> wrote:
> >
> > Good morning,
> >
> > My name is Glenn Serre, and I have recently retired from paid software
> > development work, which I had been doing since near the end of the
> > last millennium.
> >
> > I have been using gnucash on Linux for many years and would like to
> > contribute.  I intend to start by doing some conversion to C++ as that
> > will help me learn the system, fits well with my experience, and will
> > incent me to update my C++ skills (yet again).  I have read the C++
> > wiki page and intend to start with the xml backend.
> >
> > Initial questions:
> > Is there a better place to start than the xml backend?
> > Are we still limiting things to what is supported in C++ 11 and Boost?
> > Any gotchas, etc. that are not documented in the wiki?
>
>
> Welcome!
>
> I think you'll learn the Gnucash innards more quickly by taking on some engine bugs and rewriting some engine code to C++; that's where the business logic lives and it's the key to understanding the spaghetti pot; understanding the engine is a necessary prerequisite for understanding the backends. I personally find writing tests to be an excellent way of understanding how code works and there's plenty of code that isn't well tested.
>
> Regarding the XML backend, the medium-term plan is to convert the XML backend from creating engine objects directly to creating an in-memory SQLite3 database so that we can replace QOFQuery with SQL queries and towards loading engine objects as needed instead of all of them at startup. That plan argues against putting much effort into a straight functional rewrite.
>

OK.  I will look at libgnucash/engine C files and engine bugs.

> As for C++, we're up to C++17 now for new work. We do still want to limit external dependencies to Boost (although we've decided on Googletest instead of Boost::testing for the unit test framework). That doesn't mean that something else is off limits if there's a really compelling case for it, but you would need to make that case.
>

OK.  I would not expect to be arguing for additional dependencies
(fewer is better) and certainly not in the near term.

> Undocumented gotchas? You bet, including plenty of what Rumsfield famously named "unknown unknowns". Gnucash spaghetti has been cooking for 23 years now, it's thoroughly tangled!
>
> BTW, consider connecting on the IRC channel as a more conversational and (depending on your timezone) immediate channel for discussing code. https://wiki.gnucash.org/wiki/IRC

Done, but I expect to be just lurking for a while.

Thanks!
-- Glenn S.

>
> Regards,
> John Ralls
>