Boost logo

Boost :

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2006-08-21 20:18:46

Deane Yang wrote:
> Eric Lemings wrote:
>>> This brings up a good question. Say you have two objects:
>>> meters m = 1;
>>> feet f = 2;
>>> What is the type (or unit) of the following expression?
>> m + f;
> I apologize for repeating myself, but I want this to fail to compile. I
> do not want implicit conversion of units. I believe I am not completely
> alone in this view.

No, you're not :-) I too want this to fail; having the ability to
explicitly forbid on a calculation by calculation basis would not help
... forget it once, and you're screwed.

I know it has been a while, and apparently not many people were swayed,
but we did discuss this issue at length a few months back. Implicit
conversions imply choosing a "canonical" basis (or unit categories:
length, time, etc...) and system of units internally (SI, CGS). Many of
the potential users of this library have neither a need nor an interest
in doing calculation in SI (think astrophysics ... meters are not
useful!), and many of us don't have a use for the fundamental unit
categories of the SI either (length and time are the same thing, darn
it!). This also leaves out monetary units and what we have called "unit

Those of us who do lots of long running calculations in these non-SI or
non-standard unit systems seriously can't afford the accuracy damage
that loads of implicit conversions carry along -- I work very hard to
structure my numerical expressions to minimize roundoff error, and
uncontrollable implicit conversions under the hood would be very bad!
Additionally, forcing a canonical internal system makes it prohibitively
difficult to use non-standard bases (as I would like to do :-)

Which is not to say that implicit conversions aren't useful to some, I
just think that it's almost always indicative of a design error in the
application. But what do I know :-) Perhaps this calls for types that
implicitly convert, and types that don't, so that you never use the
dangerous types if you don't want them.

Oh, and I also want to be able to define my own bases and units and tags
and .... I want it all!

Kevin Lynch				voice:	(617) 353-6025
Physics Department			Fax: (617) 353-9393
Boston University			office:	 PRB-361
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA

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