This is necessary because sometimes, a post from one account will get
reported as though it were in another account (this happens with
--budget, to show child account postings within their parent account).
In that case, the account needs to remember which postings have been
reported as being within it, so that it can add these amounts to its own
total in the balance report.
It is no longer done in calc_posts, but recursively on each account.
This allows value expressions to ask statistical questions, like
"earliest cleared posting?" (TBD) from any specific account, computed
lazily.
This way, if the running total is off by a penny or two due to rounding
of one or more commodities in the account, the user will see it.
This commit also reorganizes the testing code a bit, which I did after
adding the ninth test series (ConfirmTests), to validate the new
rounding code.
The purpose of this class is much like Emacs' (interactive) form: it
allows a value expression function to declare exactly how many
arguments, and of what type, it intends to receive. It then offers
type-safe access to theese arguments in a consistent manner.
An example value expression function definition in C++:
value_t fn_foo(call_scope_t& scope) {
// We expect a string, an integer, and an optional date
interactive_t args(scope, "sl&d");
std::cout << "String = " << args.get<string>(0)
<< "Integer = " << args.get<long>(1) << std::endl;
if (args.has(2)) // was a date provided?
std::cout << "Date = " << args.get<date_t>(2) << std::endl;
return NULL_VALUE;
}
There is also an in_context_t<T> template, which finds the context type
T in the current scope hierarchy. The in_context_t then also acts as a
smart pointer to reference this context object, in addition to serving
the same duty as interactive_t. This combination of intent is solely
for the sake of brevity.
value_t fn_bar(call_scope_t& scope) {
in_context_t<account_t> env(scope, "sl&d");
std::cout << "Account name = " << env->fullname()
<< "String arg = " << env.get<string>(0)
<< std::endl;
return NULL_VALUE;
}
As you can see here, 'env' acts as a smart pointer to the required
context, and an object to extract the typed arguments.
The previous method bent over backwards to try and avoid multiple passes
through the account tree, but the result was a horribly complicated mess
that never ceased to dredge up obscure bugs. The new scheme is a very,
very simple two-pass algorithm, with multiple subpasses during the
second pass for refining the output based on the report options.
