Boost logo

Boost :

From: Phil Richards (news_at_[hidden])
Date: 2004-01-13 12:19:57


On Mon, 12 Jan 2004 20:10:53 -0700, Matthias Schabel wrote:
> BTW, I'm thinking about decoupling units
> from systems, so instead of declarations like :
>
> SI<double>::length
>
> you'd have
>
> quantity<SI,length,double>

This is exactly how my library (just posted :-) does it. Well, actually
it is the other way round, but you know what I mean.

Matthias, barring differences in how we represent the dimension list
(yours is a list, mine is fixed template parameters), there is a
significant overlap in our approaches - much of the rational stuff,
conversion, unit representation, have fairly similar layout if you do go
down this path. (I do some silly macros to make normal use bit more
friendly, in my view anyway:
  using namespace physical::si_d; // SI units based on doubles
  pq_speed s = pq_length(1.0) / pq_time(2.0);
[the pq_* stuff is the namespace si_d]
The rationale is that most of the time people will be using a single
system of units and a single value_type. Anyway, minor point.)

I have (fairly carefully) tried to avoid looking at your implementation
too much in order to approach the library from a different angle - what it
suggests to me is that, apart from the usual issues about the level of
flexibility to be allowed in defining the underlying dimensions for
dimensional analysis[*], the "common" parts of our approaches feels (even
with the differences) forms a fairly solid base for any real library.

[*] And for all the arguments, the dimension representation is *not* that
big an a problem - the dimensionality is complete separate from everything
else and can be refactored fairly trivially. In fact, maybe it is *that*
part that we should look at doing as a plug-and-play bit - people who want
a fixed list of dimensions would use one plug-in, people who want more
flexibility can use the "general" version.

Sorry, I'm rambling.

phil

-- 
change name before "@" to "phil" for email

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk