- 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 since v0.5.6 - base_type is no longer necessary as I no longer assume that conversions 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 simply provide a template specialization for the base_unit_converter class for each fundamental unit. This marginally increases the typing involved in implementing 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 become 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. Thanks, Matthias ---------------------------------------------------------------- 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 ----------------------------------------------------------------