From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-15 23:42:39
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