Re: [boost] mcs::units informal review request

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