Kevin, I appreciate your efforts to get a review in under the wire - and fully understand the deadline phenomenon. This "labor of love" has expanded to take much more time than I ever intended, and I'm glad that at least a subset of prospective users like the end result...
find the ability to define non-standard unit systems invaluable (I'm one of those "natural units for the problem" types ... CGS for E&M, solar mass/AU system for astrophysics, "hbar=c=1" for particle physics, etc).
If you ever get the chance to put a few of these systems together, I'd be happy to add them to the distro. I'm reluctant to do it myself because they are mostly outside the realm of my personal experience and I'd rather not screw them up... I think an extended set of CGS electromagnetic units (esu/emu/gaussian) with associated EM functions would be a great application of the library, since this is a clear case where getting units wrong can lead to big trouble.
I'm not thrilled with the "quantity_cast" business, but my
In the sandbox version, quantity_cast is only used for the (unsafe) operation of direct mutating access to the quantity value_type...other uses have been removed.
make useful comments. Although I note that my favorite CODATA constant (Fermi's constant) is missing ... that itself is nearly inexcusable :-)
Ouch...I only left it out because NIST doesn't provide the SI value in their tables, just GeV... I'll get right on it ;^)
I would like to see a warning on example 4 ... the presented "measurement error" type is insufficient for actual use in dealing with measurement errors, since it doesn't deal properly in correlations (quite a hard problem at compile time, I think): assuming x is a measurement<double>, with x.e the error, a correct error propagation would have (2x).e == (x+x).e == 2(x.e) whereas this class would get the addition wrong. Additionally, it is not well protected against internal overflow in the various arithmetic operation. But this isn't a review of "measurement<>", and it is overall still a nice toy example of the relevant library functionality and interface.
I'm actually thinking of including measurement<> with the library itself as a way to provide both physical constants and their associated measurement errors (from CODATA, in particular), so your comments are very timely. I was planning on tweaking the implementation, but I had naively failed to consider the issue of correlated errors... I'll have to see what's possible with a reasonable amount of effort. I certainly don't want to try to come up with a general solution for dealing with error covariances - any such solution would be messy and complex - but the self correlation case is clearly important... If you have any other ideas/input, it would be most welcome.
Examples 14, 15 and 18 could use more discussion :-) Particularly example 14, since the results seem to be highly dependent on the quality of compiler optimizations.
This will be forthcoming. We will have substantial revamping of the documentation to do. Sigh. Matthias