> On Apr 21, 2025, at 07:21, Brian Rater <blrn...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
