On 2006-06-23, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
I concur. I was already concerned with the size of PQS - recent discussions have made me distinctly worried. PQS should do roughly what it says on the tin: dimensional analysis and units. Do it small, do it tidily, do it clean. That is all very well Phil. Now where's the code?. Actually I know you have written some code. I would be interested naturally to see it.
Well, even so, I think your comment is a little bit unfair given that I have implemented most of what I've talked about in the past. I still think that PQS at 24,000 lines of code is rather on the heavy side. And all the talk I've seen is about adding more. BUt I might have missed something. It's been a long thread.
What happens when you start a quantities library is that you suddenly find the problems are a bit bigger than you thought.
Probably don't need to remind me of that...
The dimensional analysis part is frankly trivial. The bloat you talk about is the result of going into detail that previous libraries ignored: User interface, units and basic input/output.
Done basic input/output. Done *simple* units conversion (and I admit, it is nowhere near to the depth you did - and I like the ideas behind what you have done in that area, but that doesn't mean that a functionally equivalent solution to yours couldn't be achieved). Not sure what "user interface" is and I'd probably say it was subjective anyway.
IMO the other problem that previous libraries had was that they assumed that using mpl was mandatory. [...] I did so with a heavy heart because I was aware that doing so would probably kill PQS as a boost library
Don't really think it is a killer. I've done it both ways - the MPL took a lot of effort to get anywhere near reasonable compile-time performance, and even then it was at least a factor of 2 slower. So, I agree with you about not using
I mean if the problems were trivial boost would have its quantities library by now wouldnt it?
Erm, yes. One of the reasons I gave up on this whole thing (in Boost) was simply that trying to get measurable/achievable requirements was rather hard. And I can't solve problems in domains for which I have no experience without some practical use-cases.
It's nice to see that there appears to be a move in the direction of separating the dimensional analysis and units into orthogonal bits, though. It's the way I've gone... :-) Are you saying that PQS doesnt do that?
Perhaps I should have used "independent" rather than "orthogonal".
The signature of the t1_quantity is t1_quantity<abstract_quantity, unit, value_type> That looks like quite a clear separation of concerns to me FWIW. Am I missing something?
Yes. It should (ideally) be something like: dimensioned<value_type, dimension> united<value_type, unit> for any "reasonable" value_type (and both united and dimensioned would be "reasonable"). Or some such. If you only want dimensionality checking, you can have it without units. If you only want units, you can have it. If you want both, you stack them. (united<dimensioned<value_type, dimension>, unit>) Yes, I know it's not that easy. And it might even require typeof to be even slightly achievable, so might even be a non-starter. I just wish I had time to have a play with it :-) As you imply, unless I'm willing to code it, I really should shut up. So I will. phil -- change name before "@" to "phil" for email