Boost logo

Boost :

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

Hi Yuval,

> I'm not sure about that. You had two ideas, the first was to forward
> everything to the value_type, so you'll have a us_dollar value_type,
> etc. I thing it's not convenient. Most users will find something like
> quantity<currency/*, default to double*/> q1(1500.0 * us_dollar);
> makes more sense than
> quantity<currency, us_dollar> q1(1500.0);
> It certainly fits the rest of the library better, IMO. More than that,

Maybe - for me, it makes more sense to modify the value_type in this
but this was just an off-the-cuff example of how one could accomplish
varying currency conversions with compile-time dimension checking in the
simplest (from the ease of implementation standpoint) way. I'm not
sure I
agree that using a double precision value_type fits the rest of the
better, though - I have spent a significant amount of time and effort
to get
the library to gracefully and correctly handle any value_type that
the necessary concepts, so it should be value_type agnostic as much as

> the second idea of extending the SI system pretty much, AFAIU, forces
> the value_type to *not* be anything like us_dollar - it should fit
> length and mass to!

This was presented as an option for convenience; you certainly don't
to extend the SI system. But you may be right; if we're mixing
physical units
and currency units, you may need to implement specific currency
systems and
the conversions between them...

> So I believe it boils down to providing a runtime-changeable
> conversion
> ratios for some units (currency), in addition to the currently fixed
> ratios for other units (physics). Whether or not you want to
> support it,
> is a completely different matter...

You can do this already; it requires more work, because the
class (in conversion.hpp) needs to be specialized to work with
currency systems
to accommodate the time-varying conversion factor.

That all being said, I personally don't feel that dealing with
currencies (among a
number of other specialized use cases that have been proposed along
the way
during the discussions of this domain) is a reasonable expectation
for this library
to support out of the box; I have tried to make it flexible enough
to deal with a wide range of potential applications, but for those
applications that
lie outside standard dimensional/analysis and units, I expect that
users will use
this library as a foundation for their specific application.


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