Boost logo

Boost :

From: Dean Foster (foster_at_[hidden])
Date: 2001-09-24 08:52:05


> > An unit problem was that of units that look dimensionally identical, but
> > have different semantics, like regular numbers v. radians v. steradians.
>
> I don't understand what the benefit would be. I certainly like the
> idea of distinguishing between dimensions and units,
>
> Thanks,
> E

I think Daryle point is that that would give a mechnism for attaching
names to subtypes of dimensions. I'm guessing that E's point is that
we need typing not just names. I think what we actually need is some
sort of inhertence. So we can have basic dimensions (distance,
weight, energy,...) and then subtype them (weight of gold, weight of
silver, etc). So adding a weight_of_gold to a weight_of_silver would
return a weight. But it couldn't be assigned to a weight_of_gold or a
weight_of_silver.

I've been objecting to the SI_units class on the grounds that it isn't
extensable. Now I think I understand the issue better. I don't want
the ability to have new units, BUT I do want type safety. So, I'm
happy only having the SI units, BUT, I want to be able to subtype
them. We should be able to have inhertance trees that look like:

        SI_weight; // basic unit in SI;

        class metal_weight: public SI_weight { /*...*/ }
        class gold_weight: public metal_weight { /*...*/ }
        class silver_weight: public SI_weight { /*...*/ }

Then we can have signatures for functions that say what they expect.
We have both type safety AND semantic safety.

I think Daryle's point is that we want to attach a name to these
subtypes for printing. Probably this could be handled by the usual
"curiously recursive template."

        class metal_weight: public SI_weight_extender<metal_weight>
        {
           static string printable_name = "metal weight";
        }

later,

dean


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk