Boost logo

Boost :

From: Dan W. (danw_at_[hidden])
Date: 2004-01-10 21:29:05

David Abrahams wrote:
> On the other hand, premature generalization often spells design bloat
> and death ;-)

I know, been there; --2 years wasted designing the classes for a 3D game
engine, trying to cover every case, and no code. Then, one day, I
learned about XP, and in two months I had a basic engine working...

In this case, though, both tabled units libraries are already working;
but making a few assumptions, some more than others, which, to correct
them 5 years down the road would presumably break then existing code.

And some of the issues raised so far, it would seem to me, are fairly
light in terms of the solutions needed:

De-coupling the type used for unit power:
Basically placing the operators code into a class, and referring to it
via a template parameter.

De-coupling the value type:
Replacing occurrences of "double" with "V", then making V a template

De-coupling the library engine from any particular system:
Puttiog all system-specific stuff in a data file.

Full-name-ism vs. abbreviation-ism:
Providing an 'abbrv' namespace.

Waiting for MPL::map<>.

Some of the issues are a bit more involved: The convenience of automatic
conversions in some fields of application (e.g.: linear algebra) versus
the need to have no automatic conversions when, say, both millimeters
and inches need to be used, with accumulations, within the same code,
for example.
One possible solution for this that's just crossed my mind would be to
have the ability to set conversion targets:

set_target<mils>; //mm get converted to mils
set_target<mm>; //mils get converted to mm
set_target<mils,mm>; //converts meters to mm, feet to inches, but does
not inter-convert between them except explicitly.

The old quagmire of radians, degrees and raw numbers: I thought at some
point that this was a curious, but unique feature of dimensionless
numbers; until someone pointed out that Jouls are a measure of work,
whereas Newton-Meters are a measure of torque, even though both are
distance times force. So the need for semantic distinctions among
dimensionally equivalent units is not unique to raw numbers, but may
happen anywhere. This needs more thought, IMHO.

The issue of whether there should be such thing as "length", apart from
meters, inches and furlongs: This is at the core of a units library.
It needs to be settled. IMHO, named dimensions should be optional
decorations. Or perhaps they could serve an actual purpose, --e.g.: as
per the previous paragraph.

Whether there should be a run-time absolute unit == 1, with all other
units of the same dimension having run-time values != 1; or whether
each unit should be == 1 and the 'absolute' unit only exist at compile time.

The problem that some units don't seem to be made for add operations,
such as date, position, temperature; but which can only be added
differential versions of themselves, such as days, distance, and
temperature differential, respectively. Plus, many non-linear units:
decibels, Richter, and UV-ratings. Seems to me that some units will
need custom and/or customizable operator overloads.

And possibly the hardest issue to deal with: That in some models, such
as used in particle physics, inverse-wavelengts equal energy equal mass;
which is neither here nor there if we were to assume that systems are
data files with a bunch of declarations, used in isolation; but which
could be a mess to deal with if such a system had to be used together
with some other system, in the same program.

Last but not least, syntax.

The list of unresolved issues may seem long, but my experience with long
lists of issues is that once the right solutions are found, they tend to
cover most of the issues in one big swoop.


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