Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-02-06 18:04:15

> - I had to modify <boost/units/system/si/base.hpp> to include
> <boost/units/io.hpp>, otherwise the compiler claimed syntax errors for
> all of the specializations of the unit_info class.

Good point; I'll fix this.

> - Compile times even for a relatively small sample were rather large,
> but this is understandable.

Yeah, compile time is a bear. On the other hand, I haven't gone
through the
MPL code with a fine-toothed comb yet, so it might be possible to
make some
improvements there. In any case, for most projects, you would just
throw the
quantities you want into a precompiled header file, so it should
really only be
a one-time cost...

> - unit_info specializations for the CGS system typedef'd base_type as
> SI::system, not CGS::system. Is this a bug? This typedef is also
> omitted in the docs, so I'm not even sure it's necessary.

The quantity conversion code has seen more change than anything else
v0.5.6 - base_type is no longer necessary as I no longer assume that
between two unit systems have to be mediated by a base system.
Instead, as
you can see in <boost/units/systems/si/convert_si_to_cgs.hpp>, you
provide a template specialization for the base_unit_converter class
for each
fundamental unit. This marginally increases the typing involved in
unit system conversions, but significantly increases the
flexibility... I have removed
the unnecessary base_type declarations for the next version.

> So far my sample program makes two new units, nautical miles and feet.
> Nautical miles resides in SIext::system, feet resides in
> imperial::system. It then defines a radar struct that stores a range
> in nautical miles, and a ceiling in feet, as well as a location in UTM
> coordinates as meters. There is one function in_range that takes in a
> UTM coordinate and says whether or not it's in range of the given
> radar system.

Cool - this sounds like a much more interesting application than most
of the
largely SI stuff that I use it for...

> One issue that using feet brought up was how to correctly specialize
> the unit_info struct for the unit name string when the name changes in
> plural form. Could you provide a plural() function that does nothing
> but forward to name() if it's not over-ridden? e.g.
> template <>
> struct unit_info<imperial::system, length_tag>
> {
> typedef imperial::system base_type;
> static string name() { return "foot"; }
> static string plural() { return "feet"; }
> static string symbol() { return "ft"; }
> };

I guess it would not be a problem in principle to do this. Since the
current IO
doesn't use the full name anyway, you could just add plural() and
have it work.
The only downside I can see to adding this to the library (assuming I
can figure
out how to get an ostream manipulator to enable the choice of full
unit names
or abbreviations) is that operator<< would have to compare value()
against Y(1).
Another potential issue is this:

What should you call 1 lb. ft.? I'd say one foot pound. How about 2
lb. ft? I'd say
two foot pounds. But it could equally reasonably be called two pound
feet - it's
just a convention. With more involved composite units, these issues
progressively messier, which is one of the reasons why I've tried as
much as
possible to avoid the morass of IO...

> minor nit. Just in implementing this small program I was warned by
> the compiler of comparing feet to meters multiple times (comparing
> altitudes). I will try to clean up the code and send it to you if you
> are interested. I would also be interested if I used your library's
> facilities correctly.

I'd be very interested to see what you've done with it and to get
your overall
impression on the documentation and ease of use.



Matthias Schabel, Ph.D.
Assistant Professor, Department of Radiology
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
matthias dot schabel at hsc dot utah dot edu

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