Bug 739571 - Matching imported transactions doesn't indicate previously matched entries
jralls at ceridwen.us
Sun Jan 24 01:13:47 EST 2016
> On Jan 23, 2016, at 9:44 PM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
> Yeah that's essentially what I'm doing so far (although it'll need a
> bit of a rewrite if C++ isn't cool in maint). Instead of a hash table
> I'm using an unordered_map<GUID,
> TypeWhichDoesRefCountAndMatchTypeIndicator> which lives in
> _main_matcher_info and gets passed in to each match picker instance
> via gnc_import_match_picker_run_and_close. Filtering & display happens
> where you'd expect in match_update_match_model, and refcount updates
> are handled in the result of gnc_import_match_picker_run_and_close.
> Having to switch to C will take me about a day but hopefully I'll have
> something ready tomorrow.
I imagine that you're putting every proposed-match transaction's GUID in the hashtable with a flag to indicate whether it's been used or not and a ref count because you're putting a pointer in match_infos or something. I don't think you need to do that. Just add the GUID to the hashtable when the user selects the transaction for a match (and remove it if she unselects it). Then you need only do a lookup when populating the GtkListModel: If it succeeds then the transaction has already been used, if it fails it hasn't. For C++ this has the added advantage of being able to use the simpler std::vector<GUID*> and std::find instead of std::unordered_map.
A couple of notes on ref counting. First, don't ever roll your own. In C++ use std::shared_ptr to wrap a ptr that needs ref counting. In C with GObject, derive the class that needs ref counting from GObject. Second, heed the new C++ Core Guidlines (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md) and Stroustroup's recent teaching on smart ptrs: They're only needed when (potential) transfer of ownership is involved. That's not the case here with the GUID ptrs; the Transaction or Split retains ownership and we can be confident that they won't be destroyed while we're fiddling with the import, so there's no need to free them nor to worry about them dangling. Raw ptrs are fine.
More information about the gnucash-devel