Re: [Boost-users] boost::units implicit conversions

Subject: Re: [Boost-users] boost::units implicit conversions
From: Matthias Schabel (boost_at_[hidden])
Date: 2011-07-25 18:52:52

> Now I would like to start thinking more in terms of how these units-based calculations should be used by the rest of our application. Of primary concern is to receive a quantity of dimension from the application in a specified unit and to be able to perform the calculations.
> 
> One concept I've been wondering about is whether there is any value in converting units to a base unit for purposes of IPC (interprocess communication), saving to or loading from files, or that sort of thing. In this way we will know that if we see a quantity of length dimension, for instance, we can always expect the value to be presented in terms of, let's say, meters.

Implicit conversions are not allowed for a variety of reasons, but explicit conversions are and are the appropriate way to maintain an internally-consistent set of units. For example, if you have code that does some calculations with lengths, you will need to parse the input string and decide what unit was input, but then you can simply explicitly construct the quantity of length that you have chosen for the internal computation. For example, something like this :

quantity<si::length> parseLength(const std::string& input)
{
        // get unit from input string
        const int			inputUnit = getUnit(input);
        const double		inputValue = getValue(input);

        switch (inputUnit)
        {
                case 1 : return quantity<si::length>(quantity<cgs::length>(inputValue));

                // etc...
        }
}

The fact that all unit computations are done at compile time prevents functions from parsing arbitrary input; the returned unit must be known at compile time, which is the price to pay for having compile-time checking of dimensional correctness and zero overhead.

> My question concerning calculations is something along these lines: how does boost::units treat a quantity<dimension> when facilitating dimensioned calculations? Or is it on us as developers to ensure that an appropriate unit-conversion is taking place somewhere along the way when we are ready to interpret the result for display, report, or whatever?

Boost.Units only provides basic support for I/O, but, for a limited set of units this is not insurmountable. This is certainly an area that could use some improvement...

Matthias