[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [lmi-commits] master 9cbda7d 2/4: Simplify
From: |
Greg Chicares |
Subject: |
Re: [lmi] [lmi-commits] master 9cbda7d 2/4: Simplify |
Date: |
Sat, 6 Oct 2018 00:56:28 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 |
On 10/5/18 4:49 PM, Vadim Zeitlin wrote:
> On Fri, 5 Oct 2018 08:58:03 -0400 (EDT) Greg Chicares <address@hidden> wrote:
[...]
> GC> - int const length =
> value_cast<int>(operator()("GreatestLapseDuration"));
[...]
> GC> + ( !("1" == operator()("Composite"))
>
> This is unrelated to the real purpose of this commit (which is to get rid
> of the dependency on "ledger" here, IIUC),
Yes, exactly.
> but I just wonder if we have to
> write operator() call explicitly in lmi code or whether we could use a more
> readable, IMO, even if not great "(*this)("Composite")" expression instead?
My parser gags on that:
error: in cast-expression (type)(value) with
type='*this' (of type address-of-object),
value='"Composite"' (of type char const*):
Cannot cast to a memory address, which is not a type.
whereas 'operator()("Composite")' is unambiguous, though ugly.
> Independently of the answer to this question, it could make sense to add a
> named function, e.g. value(), in addition to operator() to ledger_evaluator
> as writing value("Composite") would be undoubtedly more readable than
> either of the alternatives above.
I couldn't justify a pair of synonyms, one called four times, and the
other called twice, so I just changed everything to 'value()'.