Just a reminder to interested parties - two more days left in the proposed Boost.Units review. We'd love to get some more reviews...
It is just the noncontradicted repetition of the "zero-overhead" keyword over and over again, that irritates me. This indicates that performance is not so unimportant anyhow.
OK - the library itself doesn't introduce any overhead, so in that context the zero-overhead description is correct. As we've already established, achieving zero-overhead with current compilers can be non-trivial. I will add documentation clarifying performance issues and warning library users that any use of this library in performance- critical code should be tested, etc...
a cache miss or other kinds of data dependencies may already hide this. In essence, I would qualify that library as "zero- to low-overhead".
OK - we will temper statements on performance and point out that, as the library is still in development, compiler-specific optimizations have not been undertaken for the most part.
system would be faster? I have to apologize then. I tried to convice you (and anybody else) that it would be better to have a dynamic system that is closely integrated with the static one (and vice-versa). A dynamic system enables to create additional benefits, going far
Assuming the existing library ultimately finds its way into Boost, we would be happy to work with you to provide support in integrating a run-time system that you envisage with the existing compile-time system. I have never denied the potential usefulness of runtime unit support, and would be 100% behind an effort to write a runtime library that complements this one.
Consequently, I opt against rational exponents, as I consider them to be an obstacle for such an integration.
See noise-density for an example of a unit in use that has a fractional exponent : http://swiss.csail.mit.edu/~jaffer/MIXF
Furthermore, I tried to point out that inside of computation kernels (thats where performance really matters), you probably go without any unit library.
We are investigating ways of guaranteeing that the layout of, e.g. std::vector<quantity<length,double> > is identical to std::vector<double>, so that safe casting is possible when using computational libraries that do not support units. For most compilers/ operating systems this should be the case as the quantity class doesn't have any virtual member functions or anything else that would alter the layout in memory. Matthias