Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-15 23:42:39


> 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

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at