Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-19 13:30:58

>> 3) implemented quantity_cast for three cases (see
>> unit_example_5.cpp) :
>> a) construction of quantities from raw value types
>> b) conversion of value_types
>> c) conversion of unit systems

> It isn't clear to me what the semantics of these three are. I'd

Semantics are :

a) construct quantity from value_type
double x = 10.0;
quantity<length,double> q = quantity_cast< quantity<length,double> >(x);

b) change value_type
quantity<length,double> y = 10.0*meters;
quantity<length,std::complex<double> > q = quantity_cast<
std::complex<double> >(y);

c) change unit system
quantity<SI::length> z = 10.0*meters;
quantity<CGS::length> q = quantity_cast<CGS::length>(z);

> quantity_cast should be a dimensionally safe operation. Is that the
> semantics you have in mind?

I was thinking the opposite - i was under the impression that
explicit casting
usually indicates something that's potentially _unsafe_...

> It seems like (a) should just be handled by multiplication. That is,
> double x = 42.0;
> quantity<SI::length> y = x * SI::meter;

This is the default method for quantity construction.

> For (b), it might be better to have a static_quantity_cas, as in
> quantity<SI::length> x = 42.0 * SI::meter;
> quantity<SI::length, int> y =
> static_quantity_cast<quantity<SI::length,
> int> >(x);

I guess I don't feel strongly one way or the other - using
quantity_cast as
the syntax for all three conversions is simpler since there isn't any
for confusion, but I'm happy to go with the flow if there is
consensus otherwise.

> For (c), do you mean this:
> quantity<SI::length> x = 42.0 * SI::meter;
> quantity<CGS::length> y = quantity_cast<quantity<CGS::length> >(x);
> where y ends up being 4200 cm?

Exactly. There are essentially three components to a fully-specified
the unit system, the unit type, and the value type. As it is
implemented now,
quantity_cast allows casting of all three of these...

> PS
> I must say I'm thrilled to see someone putting serious effort into
> this.
> I've thought about it for years.

I'm glad for the interest...obviously there's been a lot of
discussion of this
kind of library in Boost over the past few years. Because many of these
have been contentious, I'm trying to get as much early feedback as
possible so I can make the library as flexible as possible without
it grow beyond control... Please let me know as you have a chance to
play with the code and docs if you have other concerns, suggestions for
improvement, editorial input, etc...



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