-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Schabel Sent: 13 January 2007 05:21 To: boost@lists.boost.org Subject: [boost] mcs::units informal review request
I've been making incremental improvements (I like to think, anyway) in the mcs::units dimensional analysis and unit library. .. I'm hoping to get some concrete feedback from anyone who has downloaded and used the library (especially the v0.5.x branch).
This seems to be 'maturing' very nicely and it feels right (though my understanding of it is rudimentary). I'm impressed with the Boost Library interoperability with serialization & interval demos, and the documentation is persuasive that the philosopy is good. It is nice to see typical output from examples.
To get things started, here are a few questions I have :
1) At the moment, the library enforces strict construction; that is, quantities must be fully defined at construction :
quantity<double,SI::length> q1(1.5*SI::meters);
is acceptable, but
quantity<double,SI::length> q2(1.5);
Explicit is fine with me, but can you ease the pain? In practice, many would usually be working only with SI units, so this would simplify to quantity<double, length> q1(1.5 * meters); Or could we have SI as the template class default, or some global choice? macro? and the FPType default to double? (Since nearly all work will be done using double, it would be nice to avoid typing/seeing double so often in the code. It would be much nicer to write quantity<length> L = 2.0 * meters; // quantity of length to get double? quantity<float, length> L = 2.0 * meters; // quantity of length to get float, but order makes this impossible. And/or some typedefs perhaps ? Like typedef quantity<double,SI::length> length_type;
2) I'm not currently satisfied with the I/O aspects, particularly the lack of a mechanism for internationalization. I'd love to hear any design/implementation suggestions, especially from anyone familiar with facets/locales, on how to most gracefully accomplish this...
No advice - except that I'm sure you don't need/want to be told it is probably a nightmare. ;-) And it would be useful to consider infinity and NaNs too?
3 Is this of sufficient interest to invest the effort? IMO - No.
4) Any comments on implementation from those brave enough to look at the guts of the library would be especially welcome.
I note that the items in folder test are really examples (and might live in an examples folder (and in /libs), and that there are no tests using the Boost.Test. It is never to early to start devising unit tests, even if it seems PITA to start. But I hope to study it more closely and even try it out ;-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com