On 10/21/05, Deane Yang <deane_yang@yahoo.com> wrote:
But wouldn't it make sense to develop a core dimensions/units library without any predefined dimensions in it and develop the SI quantities library as a layer above that?
That's exactly what my library is. It's a general physical quantities library with SI just also provided as a set of classifications and units coupled with the library. Having only a fixed system would definately not be very much in the spirit of boost. The only reason I can see why one might want a fixed system would be for faster compile-times. Since a general library pretty much has to use compile-time sequences, compile-times tend to grow. For instance, right now I internally use MPL maps which still only get nlog(n) for unordered comparisons returning true, where n is the number of base classficiations of a given base or derived classification, with some cases resolving to constant time if the template for comparison with those arguments was already instantiated or if is_same reports true. A similar type of operation occurs for comparing unit types as well. Those operations generally have to be done for any binary operator expression having two quantities for operands, since it usually has to be determined if they are of the same classification first, and has to compare the unit types of each operand. Unfortunately, I see no way around this for a general library and am pretty sure that nlog(n) is the best we can do, which is unfortunate (which is why earlier I challenged someone to figure out a better way). How much this will actually impact compile-times in practice is still hard to tell at this point in development, since many of those operations will likely be redundant template instantiations, meaning you should only have that compile-time overhead once per set of arguments and then it's almost free after that. Exactly how often the same arguments happen to be passed is difficult to tell without using the library in practice, since the order of elements in compile-time associative sequences are dependent on the way in which the sequences are created and modified. Not only that, but nlog(n) isn't a terrible complexity anyway, especially considering most of the classifications will only have between 0 and 5 fundamental classifications or units which make them up. Still, it's obviously not better than being always performed in constant time, as if a fixed set were used. There is another solution I have come up with, though, which has the benefits of both approaches. If compile-times prove to be too long, an adaptor could be developed which takes a group of classifications created by the general library and converts them to a "system" such as those described earlier, where you can optionally only use units together from that system in certain contexts. Such a system could often have constant time classification comparisons as well as have other optimizations unavailable with a strictly general approach. This would probably be the ideal solution, since you still have the general library as the basis and are able to use all units with each other when needed, but you can also optionally pull a subset of any of the infinite number of classifications which could be created for that library into their own subset for situations which need better compile times or which you don't want to intermingle with other units. Not only that, but since the classifications of those systems come from the general library, an explicit conversion could easily be made to convert quantities back to a general representation to be used with any other units once calculations are done on them in the fixed system (not a good idea to have such a conversion implicit since it defeats the purpose of systems). This way, you can create systems for optimizations or just for logical groupings without impacting how general the rest of the library is, and it doesn't make the overall library much more complex either. I'm not going to think about creating such an adaptor just yet since I'm caught up with finishing the rest of the general library, but I'm tossing the idea up into the air for people to see. It should provide a way to have the best of both worlds without having to have two completely separate libraries, and it wouldn't be too difficult to implement once we get to that point in time. Opinions on such an approach would be nice now, though. On 10/21/05, David Abrahams <dave@boost-consulting.com> wrote:
Matt wasn't talking about that "feature." Note that the implicit conversion he mentioned is a widening one, which is always okay.
Thank you! Someone understands the point I was making. I was a little worried when everyone started talking about unrelated conversions after that post. -- -Matt Calabrese