On 3/27/07, Noah Roberts <roberts.noah@gmail.com> 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