QIF Import C++ Conversion status

[John Ralls]

> 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/57c4a769/attachment.htm>