From: Jeffrey C. Jacobs (darklord_at_[hidden])
Date: 2002-10-17 12:51:52
Well, IMHO I am bias as I too was working on something like this but am not
production-ready so if Vladimir is happy with it I suppose I can support it
if only for the like-minded sentiment that SOME units library would be
That having been said, in general I would prefer something a little more
like the FermiLab approach as it seems more intuitive to me. Namely, it is
nice to simply be able to write:
5 * cm;
Which is what is happening intuitively IMHO. I think the idea of
pre-defining cm and ALSO not polluting the global namespace with it
(si::abbreviation::cm) unless the client wants to is a nice touch. I do
agree that compile-time structs are probably best and done via MPL strikes
me as the right way to go. However, I am also a bit squeamish at any sign
of code bloat. Happily you are only defining typedefs and empty structs
which should not generate any compiled code so this I like!
FermiLab's approach does seem to lack an MPL touch so I will say in this
sense I like what you have done.
I am though a bit concerned more with practical issues. Generally, typedefs
can fix the unreadable (IMHO) some_unit_t, like in the FermiLab software for
Length, Width, Area, etc. And clearly the "cm" is a object and thus takes
up some space in run-time code where as your approach, in not allowing type
qualifiers, makes the code lean and mean. IMHO, again I like the
"modifiers" approach for building numbers, but to do so in such a way that
they can be included modularly: if you don't use it, you don't pay for it.
A hybrid between your Spartan impl and Fermi's bloated one is what I'd
prefer as far as code readability.
Now, as for output, I have to admit preference to a different approach.
Basically, as I see it there should be unit types (Mass, Volume, Time,
Luminescence, [Electric] Current, Temperature per Radian, etc.) as well as
units (kg, l, yr, cd, a, K/r) and that the former should be true types and
the later a modifier for immediates. Note also that although SI does not re
cognize the dimensionless Radian and Striation, I think as a part-time
physicist I'd like to know when I'm dealing with "radian per second" it is
not confused with Hz (cycles  per second). But for output, what strikes
me is how you have each type return its representation. Granted, this is
part of a "Policy" which I think is the right approach, but OTOH, I am
currently of the mind that std::facet is an underused aspect of the standard
library. IMHO the representation of kiloliters or meters cubed or m^3 or
m**3 or m3 should be configurable via imbuing the output with a facet based
on unitRepresentation : public std::facet. Then, to change the output one
can derive a class from unitRepresentation replacing "K" with "*K" or "K*"
depending on the programmer's preference. Granted this is the same
mechanism I would use to create a custom kelvinPolicy-derived class to
replace the representation, but to me I like the idea of abstracting the
output from the type.
As for unit conversions, I think this, like any scientific Unit library in
general, requires a "significant_digit" library like the one on which I am
working. Thus, as I have already greatly researched, converting between lb
and force-kg (kN) would be only as accurate as either a) your source data or
b) the conversion factor (about 7 digits IIRC). I have already implemented
a library based on the assumption that 2 numbers with given error x+/-dx,
y+/-dy can be manipulated in any of the built-in operations including sin,
exp, etc. under the assumption that x and y are both independent, random
variables. If there is a dependant relationship between x and y, I would
have to take the partial derivatives of xdy and ydx (normally 0) into
account. This would then have to be implemented as a "sci_number" policy
IMHO, but that is another thing I will save for later. Your library would
allow abstract data types on the fly as it were, unlike FermiLab which has
the type compiled in to the library. I would therefore only caution that
Unit Conversion should be easily separable (another Policy??) from the
unit-library proper to allow for those who want numbers with errors and
those who don't.
I think that is all, but in any case thanks Vladimir for bringing this to
our attention! It is IMHO a cool thing to add.
"vladimir josef sykora" <vladimir.sykora_at_[hidden]> wrote in message
> Greetings boosters,
> I've been working for some time now on a physical unit's library that I'd
> like to submit to boost. It uses the concept of generating units out of
> physical dimensions. It provides type-safety and implicit conversion
> units using operators.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk