AMDG Noah Roberts <roberts.noah <at> gmail.com> writes:
Steven Watanabe wrote:
std::cout << (x + y) << std::endl;
Nothing good would probably come of it the way I see things; but since mcs does magic unit label stuff it could just output that. Without, allowing for the user to override certain behavior this could be more well behaved:
std::cout << ((x + y) * unit) << std::endl;
You're probably not too worried about the moderate overhead of the extra work there when I/O is going to be bottlenecking anyway.
Except in debugging, the developer is going to have a pretty strong idea of what units need labels and create them. Other units and dimensions are of no consequence.
Agreed. If you have to specify the unit at this point, what is the purpose of tracking it dynamically at all, though?
Yes, there is an overhead to the unit but it is localized to the places where conversion is necessary. The library user does have to use some care, and I haven't thought of a way to allow them to use this stuff willy nilly in something needing extreem performance, but I don't think that is too much to expect.
I'm afraid that I am still unconvinced that runtime units are useful. Here are the basic scenarios and solutions. Perhaps I forgot something? 1) The dimensions are known at compile time but the unit system depends on user input. a) Losing a few bits of precision doesn't hurt. Do all internal calculations in SI (e.g.) and track the units to print separately. The printed units need never appear anywhere outside of the IO code. It is cleaner to keep them there rather than having them possibly propogate out, only to be translated immediately into SI anyway. b) Every bit of precision matters. Track everything at runtime using sorted vectors of fundamental units. If perfomance also matters then there is not much that a library can do to help. In Christ, Steven Watanabe