QIF Import C++ Conversion status

[Brian Rater]

Great, thanks for the feedback.

On Mon, Apr 21, 2025 at 2:36 PM John Ralls <jralls at ceridwen.us> wrote:

>
>
> On Apr 21, 2025, at 07:21, Brian Rater <blrnh94 at gmail.com> wrote:
>
> About this time last year, I said that I was interested in converting the
> QIF Import to C++.  I did some top level investigation for a couple of
> months to figure out a path forward, then work and life got in the way and
> I had to set it aside.  Now I am retired and caught up on everything, so
> I'm starting to get back into this project.
>
> I don't want to make any changes to the UI code more than necessary.  I'm
> learning a lot here - gnucash, glib, scheme - trying to figure out a UI
> toolkit that I'm not familiar with seems too much, especially given that I
> am still learning the functionality of the import itself.
>
> The path that I have been experimenting with is to create a thin C API
> layer to wrap the (not yet designed) C++ interface and update the GUI C
> code to replace all scheme calls and data structures with C API calls.  All
> non-gui data structures would be moved into the C++ implementation.
>
> Let me know if there is another direction that would be preferable.
>
> Where my sandbox code stands right now is that I have a version of the UI
> code that replaces all guile with C calls.  The C calls are not implemented
> and need better organization and documentation if I continue down this
> path.  The C++ interface design would be the next step after that.
>
> I plan to submit the project for review at various phases - defining the C
> API, defining the C++ interface, multiple implementation  and test reviews.
>
> For the C++ classes, I am planning to create a set of base classes that
> can someday be used as a basis for new implementations of other import
> functionality, and QIF specific classes that inherit from these base
> classes.
>
>
> All of the UI is in assistant-qif-import.c and dialog-account-picker.c.
> Change those to cpp and wrap the decls in the corresponding headers with
> `extern “C” { }`. You’ll find abundant examples throughout the code, just
> pick a .cpp file and examine its header. You may also have to do a little
> fixing up of the code to make the stricter c++ compiler happy. Feel free to
> modernize things like NULL -> nullptr, moving local variable decls to their
> point of first use, using `auto` and `constexpr` where appropriate, and so
> on—but don’t feel obliged to either. With that change you’ll be able to use
> C++ objects directly, no C wrapping or even `extern “C”` decls.
>
> Please name the C++ class headers foo.hpp to make it clear that they’re
> for use by C++ only, and note that you can use the engine C++ classes like
> GncDateTime and GncNumeric directly as well instead of using the
> gnc_numeric and gnc_datetime  C wrapper functions.
>
> Don’t rewrite qif-guess-map.scm, use
> gnucash/import-export/import-main-matcher instead.
>
> Prefer std:: and boost:: for dependencies, but please avoid the boost
> monsters asio and spirit. If you’re  I’m open—in fact, I *encourage* you—to
> consider using  https://github.com/fmtlib/fmt and
> https://github.com/hanickadot/compile-time-regular-expressions; you can
> add them to borrowed.
>
> Regards,
> John Ralls
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20250421/de112e7c/attachment.htm>