Boost logo

Boost :

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;
   return quantity<SI::length>(dist);

--Michael Fawcett

Boost list run by bdawes at, gregod at, cpdaniel at, john at