Michael, Michael, Thanks for your positive review. I'm glad that the library is working for you in a practical setting - that's always a concern for us academics divorced from the real world ;^)
specialization is simply the reciprocal of the first. Steven posted a solution to this in a separate thread just now and I hope that it will get included in the final version.
This should not be a problem; I'm accumulating a list of changes to be made as they come in.
Example 16 looks strangely familiar! Glad to see it was interesting enough to make the examples.
Your example was actually the impetus driving the decision to implement heterogeneous units, a project that I know Steven spent a significant amount of time and effort to get right...
sure if this unit makes sense in the nautical namespace. One might ask "Why not boost::aerial?" The only reason I bring this up is because they are used for marine and aerial navigation. There may be
I tend to try to name things so they sound right if you read them; even though they are used in aerial navigation, as far as I understand they are still called nautical miles, so to my eye nautical::miles reads right.
other such examples, but I think all of the non_si_units.hpp units could reside in a boost::non_SI namespace with little confusion to the user. These would be all non-SI, but accepted, units (see http://en.wikipedia.org/wiki/Non-SI_units_accepted_for_use_with_SI).
This is probably one of the darker corners left in the library; I'm hoping that reviewer input will help to shape the final form of the non-SI portion of the library. Steven has some ideas for dealing with the irregularities of US/Imperial units in a relatively clean and elegant way. However, putting all of these into the same namespace is problematic because there are, for example, differing definitions of units having the same name (mile, in particular) so us_customary, us_survey, and nautical miles are all slightly discrepant.
I also noticed that the unit knots was not defined in non_si_units.hpp. Is this an oversight? Why are some accepted non-SI units defined and others not?
I just have very limited personal experience with and use for these traditional units, so I didn't think to add it. I'm certainly happy to put knots in. I don't believe they were listed in the NIST documents I was referencing. Because there are so many irregular units out there, I'm reluctant to promise to support everything under the sun in the library, but the decision of where to stop is a bit arbitrary. I just used the NIST document as my yardstick (sorry...)
Is there an exhaustive list in the docs mentioning all units and their systems?
There is not yet, but should be.
Yes, certainly. I would, however, like to hear Matthias' and Steven's thoughts on how easy it would be to add a run-time layer on top of their existing work.
A runtime component would be essentially a parallel library that replicated the existing dimensional analysis functionality in runtime code. I've mentioned previously that it would be relatively easy to specialize to get a syntax like quantity<arbitrary,Y> that looks much the same as the existing syntax. It probably wouldn't be hard to implement runtime algorithms; I am still extremely skeptical that there are many users out there who would be willing to pay the computational cost and memory overhead of doing all of the dimensional analysis at runtime. At a bare minimum, I would like to see some "real" use cases where it isn't possible to get reasonable behavior with the existing library. As you mention, the current implementation works fine with GUIs as long as you're willing to pick an internal representation for the units used at compile time. There would also need to be compile-time -> runtime conversions, input parsing, etc... which would involve varying degrees of effort - the latter probably will be hardest... Matthias