Re: [boost] Boost Units library preview

From: Dave Steffen (dgsteffen_at_[hidden])
Date: 2006-08-21 20:09:55

Andy Little writes:
 > 
 > "Dave Steffen" <dgsteffen_at_[hidden]> wrote in message 
 > news:17642.14441.683655.649056_at_yttrium.numerica.us...
 > > Eric Lemings writes:
 > > [...]
 > > > > >>> 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.
 > > >
 > > > Could you provide your rationale for wanting expressions like this
 > > > to fail?  Maybe there is something we've overlooked?
 > > >
 > > > > Personally I love implicit unit conversions. :-)
 > >
 > > Comment from the back row:  Some people will want automatic
 > > conversions.  Some people will want a compilation failure.  Both are
 > > perfectly reasonable behaviors, and which one is appropriate is
 > > project specific.
 > >
 > > If (either) units library fails to provide both capabilities, it will
 > > be unusable for some category of projects.
 > >
 > > I don't know how to control this, nor what the interface should look
 > > like, but I am certain that a good units library will be able to go
 > > both ways.
 > 
 > What? By means of a Macro switch in the config header?

 I don't know.  Yeah, maybe.  Or maybe by having two namespaces, and
 the user grabs stuff out of namespace UnitConverts or namespace
 UnitsDontConvert.  The mechanism is a design decision; I'm just
 saying that the users are gonna want it.

[ and in another email ]

 > BTW what is wrong with a nocast(t) scheme ?

Ugly. Not syntactically easy, simple, and obvious.  If people are
going to really use a units library, the syntax has to be
indistinguishable from builtins.

Note that an automatically-unit-converting library can use a nocast
scheme (I think that's what nocast() means), while an
automatically-non-unit-converting library would support unit
conversions via explicit casts, e.g. overloading static_cast or
numeric_cast or something.  It's really a question of what the default
behavior is.

I think there are two completely different uses for this library.  On
the one hand, units are handy to have around if they do all the unit
conversion for you, so you never care if a temperature is in
Farenhight, Celcius, or Kelvin; they all work out the details.

On the other hand, for other applications, adding feet and
meters is indicative of a serious programming error, and _must_ fail
compilation.  (E.G. that unfortunate Mars probe.)

Succincly, the former is convenience, and the latter is correctness.

Both are legitimate uses, but they demand very different semantics.
If you're going to provide both semantics with the same library (which
I think you should), you need a way to specify which one you want, in
a way that looks very natural; which IMHO means that the unit-full
objects walk, talk, smell, and taste like builtin types.

I don't know how to do that, but I'm absolutely sure it's what your
users want.

----------------------------------------------------------------------
Dave Steffen, Ph.D.      
Software Engineer IV              Disobey this command!
Numerica Corporation                 - Douglas Hofstadter
dgsteffen at numerica dot us