The basic gist of the discussion is that many generic libraries don't fully support Boost.Units because they don't support mixed type arithmetic correctly (or aren't generic enough, however people want to say it). Consider a very simple example of a hypothetical math library function "add" that purports to handle user defined types (some sort of BigInt is a popular example):
template <typename N> N add(N lhs, N rhs) { return lhs + rhs; }
Functions like this often break with Boost.Units because the result type might not necessarily be the same as the argument types (N in this case). Not only that, it doesn't allow adding two distinct types together.
It's not that they're "not generic enough", it's that they use different concepts for their number types, Boost.Math has a well defined concept that all number types must obey: http://www.boost.org/doc/libs/1_47_0/libs/math/doc/sf_and_dist/html/math_too.... It also has concept checking programs and concept archetypes to verify that our code really does stick to the stated concept requirements and no more: http://www.boost.org/doc/libs/1_47_0/libs/math/doc/sf_and_dist/html/math_too... The issue is really twofold: * What are the conceptual requirements for a unit type? I can't see it listed anywhere, but that doesn't mean it's not there (In point of fact, Boost.Units has two concepts in play: the requirements on a backend type supplied as a template argument to type "quantity", and the requirements on clients of quantities). * Should we have a single unified concept for all number types in Boost.... if yes what happens when the next latest and greatest library comes along and requires slightly different concepts to function efficiently? What I'm saying is it's pretty hard to get this right. Let me give you a concrete example - mixed arithmetic. Boost.Math currently requires code such as: x *= 2; to compile and do the right thing. However, there are some number types (Boost.Interval for sure, not so sure about Units) that don't permit this and make all constructors explicit. Now you could say, "no problem, just add a cast", but: x *= SomeType(2) Is needlessly inefficient for many big number types, and even for builtin floats, one could imagine a sufficiently clever compiler just doing some bit fiddling in x, rather than a full multiply. Basically, the issue is that it's really hard to come up with a clear conceptual model, that satisfies all potential use cases. A worthy goal for sure, but what I'm trying to say is it's the detail that gets you ;-) If someone would like to try and work up a unified set of conceptual requirements that would be really great, but I'll warn you now it's likely to be a whole lot of work. Perhaps as a more manageable goal, if someone can provide unit-aware-and-safe signatures for the math lib's functions, then I'll happily provide them as thin wrappers that forward to the underlying non-unit aware code. Rather like the Units lib already does for std lib functions. I'd rather not do this myself though, as I'm not familiar enough with Boost.Units. Regards, John.