Nic Holthaus

@pattop I definitely want to be able to use John's fixed-point types as underlying types (and he really wants me to as well). I haven't done much work on it...

@johelegp I'm planning to split the unit definitions into different headers to reduce compile-times. I'm not really sure what the best way to deal with the name clashes from different...

@johnmcfarlane totally agree with you on that. I Wish libraries like ours could create new fundamental arithmetic types (or something that was equivalently treated), but I'm guessing that would fall...

@johelegp getting this thread back on track, yes, units are all aliases, but they don't really have to be. If we made the units structs that were inherited from the...

OK, it's officially on the list. I have a feeling it will make a lot of the error messages easier to read too.

looks like an oversight when I added those operators. The dimensional analysis should all be constexpr, but if you find holes obviously let me know. The cmath functions, aside from...

@dhouck like @johelegp it's not supported in v2.3.1 but will be in v3. There will be some macro wrapper around the example above that will simplify defining dimensions, and examples...

an aside: the problem with monetary units for _this_ library has always been that (most) conversions can't happen at compile-time because you'd have to tie in to some exchange-rate database,...

@johnmcfarlane and @Morwenn make good points. That said, we're stripping out all `_t` naming conventions 3.0. Early on in the library development, what are now known as 'conversion factors' (basically...

Thanks! I'll definitely add these to the next release. Out of curiosity, what kind of application is it for? In the meantime, the library is powerful enough that you can...