Better c++

[christopherlam]

to be selectively merged after 5.7.

• adds an overloaded gnc_account_foreach_descendant for c++ use.
• use c++ containers instead of creating new GLists

[jralls]

to be selectively merged after 5.7.

That would be better as multiple PRs. It's ok to make a chain of them, just say in the comments who depends on who.

[jralls]

That last commit about centralizing GValue got me to realize that since you're writing C++ here and accessing the KvpFrames directly, there's no need for GValues at all, use KvpFrame::set_path(std::vector<std::string> path, KvpValue* value) and KvpValue* KvpFrame::get_slot(std::vector<std::string> path). To get a particular type for the KvpValue* use value->get<T>() substituting the type you want for T, as in value->get<time64>();. To create a KvpValue you can just construct it from the source variable KvpValue val(the_time);.

Edit: Better yet move them to qofinstance. The whole point of the GValue dodge was to provide a generic interface similar to g_object_[sg]et for C code. It doesn't make sense to have a bunch of set_kvp_foo_path functions wrapping the abstraction. You could go full C++ and do

template <typename T> T
qof_instance_get_path_value(QofInstance* inst, Path path)
{
     auto kvp_value{inst->get_slot(path)};
     return kvp_value->get<T>();
}

template <typename T> void
qof_instance_set_path_value(QofInstance* inst, Path path, T value) 
{
     KvpValue kvp_value(value);
     inst->kvp_data->set_path(path, kvp_value);
}

Then to handle the edit level and marking-dirty in Account.cpp you'd have

template <typename T>
set_slot_from_path(Account* acc, Path path, T value)
 {
      xaccAccountBeginEdit(acc);
      qof_instance_set_path_value(QOF_INSTANCE(acc), path, value);
      mark_account(acc);
      xaccAccountCommitEdit(acc);
}

When calling qof_instance_get_path_value you'll specify the type that you want, e.g.
qof_instance_get_path_value<gnc_numeric>(acc, path);.

[christopherlam]

That last commit about centralizing GValue got me to realize that since you're writing C++ here and accessing the KvpFrames directly, there's no need for GValues at all, use KvpFrame::set_path(std::vector<std::string> path, KvpValue* value) and KvpValue* KvpFrame::get_slot(std::vector<std::string> path). To get a particular type for the KvpValue* use value->get<T>() substituting the type you want for T, as in value->get<time64>();. To create a KvpValue you can just construct it from the source variable KvpValue val(the_time);.

Edit: Better yet move them to qofinstance. The whole point of the GValue dodge was to provide a generic interface similar to g_object_[sg]et for C code. It doesn't make sense to have a bunch of set_kvp_foo_path functions wrapping the abstraction. You could go full C++ and do

template <typename T> T
qof_instance_get_path_value(QofInstance* inst, Path path)
{
     auto kvp_value{inst->get_slot(path)};
     return kvp_value->get<T>();
}

Not quite because kvp_value may be a nullptr. Also the get_kvp_boolean_path is a polyglot.

Edit: alternatively we could return std::optional<T>

[christopherlam]

The last issue is the optional<optional<numeric>> which I admit is confusing but I'm not sure where to initialise the balance limits except on the first getter call.

[jralls]

If you're going to bury the template declaration in a cpp file, which speeds up compilation especially when rebuilding and avoids ODR problems if the template gets used with the same args in more than one compilation unit, then you have to force instantiation in the cpp file for all of the types you want to use it with. That's just some simple declarations, see gnc-options.cpp for examples.

[jralls]

note these are overloaded functions returning type T instead of
getting/setting GValues

That's unclear. They're template overrides with std::optional replacing the GValue containing T.

This is pretty close, just a few tweaks left.

[jralls]

I still want the QofInstance* NULL check in qof_instance_get_path_kvp and get_kvp_gnc_foo_path removed.

You made a typo in your last commit that causes tests to fail.

[christopherlam]

if the last two are ok I'll tidy up and merge in.

[jralls]

Not quite, you went in the opposite direction I had in mind. The null/wrong type check needs to be at the lowest level to protect against some future use that doesn't do it. There's no harm in doing it also nearer the source to make a more usefult tracefile.