Paul,
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.
Thanks for the positive feedback.
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);
Right now you get this syntax is you (gasp) do using namespace SI;
Or could we have SI as the template class default, or some global choice? macro?
This is somewhat problematic with the current implementation because the unit system is encapsulated as a template argument of the unit, which is itself a template argument of quantity. I'll have to think about it a bit more...
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.
As I mention in my previous post, I could easily add a quantity in the SI namespace that allows double precision by default and inverts the order of the template arguments. I am also not strongly opposed to flipping the order in quantity itself, so the value_type is the second argument: template<class Unit,class Y = double> class quantity;
And/or some typedefs perhaps ? Like
typedef quantity<double,SI::length> length_type;
I already have typedefs for units themselves: typedef unit<SI::system,length_type> length; but would be happy to add quantity typedefs, too. You're probably right that a simple double-precision SI unit set is going to be by far the predominant use case in practical code... Maybe typedef quantity<double,SI::length> SI_length_q; (analogous to time_t nomenclature)? Or I could rename the unit typedefs to length_unit, etc... to free up the simpler typedefs: typedef unit<SI::system,length_type> length_unit; typedef quantity<double,SI::length_unit> length; I'd be happy to hear additional opinions/ideas about this point...
No advice - except that I'm sure you don't need/want to be told it is probably a nightmare. ;-)
Harrumph... I may have to do the unthinkable and buy Langer & Kraft's book...
And it would be useful to consider infinity and NaNs too?
IO of value_type will be delegated to the value_type itself, so this is decoupled from the library.
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.
Good suggestion - I'll make the move for the next release. Anyone know of a good tutorial on using Boost.Test?
But I hope to study it more closely and even try it out ;-)
Please do, when you have a chance. I'd like to optimize the chances for success before submission, especially given the general level of contentiousness that this issue seems to have generated in the past... With a little luck I'll be able to have default behavior that makes most people reasonably happy, then facilitate enough flexibility to accommodate those with other needs relatively easily. Matthias