lmi
[Top][All Lists]
Advanced

[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()'.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]