Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2003-11-20 20:58:20

        From: Matthias Schabel <matthias_at_[hidden]>
        Subject: Re: [boost] Re: new compile-time dimensional analysis and
unit library
        Date: November 20, 2003 6:57:19 PM MST
        To: Boost mailing list <boost_at_[hidden]>

> As I said later in last post . Its pretty trivial to add explicit.
> In the above context this is a policy.
> BTW I use explicit on initialisation by value.,
> but I would argue that is structurally necessary to prevent pq falling
> apart. If not:
> pq_velocity<>::m_per_s v1(1),v2(2);
> pq_force<>::N f = v1 / v2; // no
> error

Of course, I would say that this is an argument for retaining
types as distinct and _without_ implicit conversion. In that case, the
of dividing two velocities would be dimensionless and could be used, but
only with explicit conversion. The "experts" tend to also view implicit
conversions as dangerous :
Meyers, More Effective C++ pg. 24-31

> If its contentious I would be strongly in favour
> of a switch for make unit conversion explicit yes or no.
> Of course it would have to extend from no, else it would break my code.
> Start off less restrictive and then impose the policy.

On the other hand, if you're building a library, it's much easier to
start out
with a more restrictive interface and wait to see if the users actually
enough problems with said restrictions to justify broadening it...
That is, if
the initial release disallows implicit conversion, it can always be
added later
without breaking code conforming to the initial release - the opposite

> Yes I see your point.. well sort of. My immediate thought on
> implementing
> arrays/vectors would
> be just as a a vector of pqs... presumably the above has advantages
> over
> that scheme ?

Efficiency - the units can exist on top of existing data vectors as a
containing wrapper, sparing the cost of copying _many_ data elements
at the same time enabling unit correctness :

// double *in,*out; -> large vector/matrix which has been allocated

SI<double>::Mass M(in); // -> constructs using reference for non-POD
SI<double>::Energy E(out);

function_using_units(M,E); // does dimension checking with no runtime

Otherwise you'd have to copy data back and forth (or use nasty

> BTW boost::array<double,5> does that work ?

> Incidentally one( real or imagined) problem with use of a lot of MPL is
> compile time.
> its a dirty word but has to be taken into account in a practical
> system.
> if it takes too long to compile,as a user I wont use it - end of
> story.

Unless you're writing a program which uses a tremendous number of
fundamentally different unit types, each type and the associated code
should only be instantiated once, so compile time should be relatively
irrelevant. Of course, the codes I'm working with involve 3D data sets
of up to 256^3 voxels and similar sized PDE solvers, so the compilation
time is negligible compared to runtime...

> Overall I hope you would agree that some documentation would help
> to convey the ideas behind your library. (I am working on that for
> mine but
> takes time !)

Agreed - anyway, if we're the only two on this list who are interested
in such
a beast, which I'm starting to suspect from the general lack of other
it may not be worth expending a tremendous amount of energy in

> My current view is that we should keep the two ideas separate
> initially, do
> more work and see how each works in practise.

Certainly - I think we need outside comment to ascertain which solution
is most

> basically no direct relationship betwen angle and pq.
> Let the programmer decide

There are many cases of equations which are expressed in terms of some
quantity per radian or steradian - even though these are not properly
quantities (being, in fact, dimensionless types expressed as
length/length or length^2/
length^2) .


Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu

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