From: Paul A. Bristow (boost_at_[hidden])
Date: 2004-01-15 16:04:06
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]]On Behalf Of Kevin Lynch
| Sent: Wednesday, January 14, 2004 8:13 PM
| To: Boost mailing list
| Subject: Re: [boost] Re: Re: Re: Re: Physical quantities
| a DA+unit framework that doesn't include the flexibility to include many
| is not going to be particularly useful to the communities that need that
| flexibility. and I suspect that those communities are the ones that
| will be most likely to use such a library.
I suspect that you are right.
| If we had a good, flexible DA+unit system for me, I could use it to
| define the time unit in terms of taus instead of seconds, and use the
| equation in its original form, and still get the aesthetic and technical
| benefits without teh work of non-dimensionalization.
When we discussed this some years ago, this seemed way beyond the reach of
anything in C++ and so many favoured what seemed the only attainable target of
an SI-only system. It turned out to be unattainable because few compilers could
handle even that.
But now all the compilers are much better, and MPL has been devised and tested.
So I agree that a framework has become a SMART target.
The snag seems to be compile time, but I think that there are grounds for
1 Processor speeds continue to increase steadily.
2 Future compilers should handle template and MPL code faster.
3 There are several suggestions for improving the MPL code.
4 We haven't even explored writing programs to generate C++ code for each units
system. This would be a dirty solution but might produce much faster
Using MPL does this elegantly, but is re-done every time.
5 When I created an naively artificially longer programs by pasting the 'demo'
code in half a dozen times, the compile time hardly increased at all. So for
realistic amounts of code, the EXTRA compile time may yet be acceptable.
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk