Matthias Schabel wrote:
Hi Noah,
Would something like this work for creating a quantity that's unit can change during runtime and allow support for multiple units all converting to a particular "system" (as you specify the meaning)?
I am drawing a "line in the sand" at implementation of runtime unit systems; this is not because it can't or shouldn't be done, but because it is basically a completely different problem domain with different objectives and performance criteria.
I think it is a definite must that any unit library needs to be at least extensible to support the two problems I described. I personally don't see much use in being able to convert, statically, between two disparate unit systems. I don't know of any project that would do this. Perhaps for times when you are using third party libraries that assume one set of units while you work in another this would be necessary but that doesn't seem a general enough problem for a boost library and both would have to use this system. The primary goal of a boost units library should be to support safe unit conversions of user defined units in a way that ensures that conversions are safe and inexpensive (as in not done more than once per assignment) and the primary use of this will be during runtime. I was hoping that your library could be used as a base for such a runtime solution but you make it sound like more trouble than worth. I will probably continue to look at ways to work this in, especially if you get accepted, but since I already have a very simple answer to the problem it may be placed on the back burner. It would be nice to be positive that units share the same base system and provide a general solution when they might not but I really think, practically speaking, that the likelihood of someone needing to have two different static base systems is next to nil. I don't believe Andy's problem was that runtime units are too large a problem but that these unit libraries try to do too much in static mode. It certainly makes for a great excercize in tmp but without support for conversions to arbitrary, runtime selected, units I don't see how they have a whole lot of practical value. By support I mean either built in or easily extended in a well documented manner. You have a great library, something that might be a great backbone for a runtime units system and provide an extra level of safety, but I think the primary use to most people of a unit library is going to be runtime units you either need to support this directly or better document the methods to use your library for such purposes. 99.99% of the time users are going to stick with a single system, usually the SI system, as their static set of units and will need to do a lot of conversions into and out of these base units. I understand your desire to keep your library simple and to a single task and goal, but I just don't see much need out there for a library that does static unit conversions but has no concept of runtime units.