Re: [boost] [Review] Quantitative units - compile time vs runtime

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-03-28 10:41:38

On 3/27/07, Noah Roberts <roberts.noah_at_[hidden]> wrote:
>
> Nope.  Your dialog manager would keep track of the unit and set
> appropriately upon initialization and/or user interaction.  Your reader
> would then be as simple as setting the value directly to the quantity.
> Alternatively you might have something like this:
>
> quantity<abstract> on_dialog_ok()
> {
>    quantity<abstract> dist;
>    dist.set_unit(combo.selected_item().data());
>    dist.set_value(entry.value().as_double());
> }

I see.  Would the implementation allocate a derived class based on the
unit type, or just dispatch during arithmetic based on unit type?  I
suppose it works out to about the same penalty either way, virtual
function or if statement for every arithmetic.  It would probably be a
lot cleaner to go the derived class route though.

> No more switch statement smell.

I agree on the smell...Thankfully it's very contained when using the
compile-time version.  It seems like with a run-time component that
was interoperable with the compile-time one, you could have zero
run-time overhead during computations as well as get rid of all switch
statements at the boundaries (reading/writing from database or GUI).
Something like:

quantity<SI::length> on_dialog_ok()
{
   quantity<abstract> dist;
   dist.set_unit(combo.selected_item().data());
   dist.set_value(entry.value().as_double());
   return quantity<SI::length>(dist);
}

--Michael Fawcett