"Deane Yang" <deane_yang@yahoo.com> wrote in message news:ecd87h$brg$1@sea.gmane.org...

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.

Personally I love implicit unit conversions. :-) I can add a function to prevent them, but you will have to apply that explicitly: T b = no_cast(a); or some such. How's that? regards Andy Little

Andy Little 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. Personally I love implicit unit conversions. :-) I can add a function to prevent them, but you will have to apply that explicitly:

T b = no_cast(a);

or some such.

How's that?

regards Andy Little

For addition you would need to do this:

nocast(a) + nocast(b);

for multiplication

nocast(a) * nocast(b);

You could make this a general purpose utility:

template <typename T> struct no_caster{ T t; /*...*/ };

template <typename T1, typename T2> typename boost:enable_if< boost::is_same<T1, T2>,T1

...

::type

operator Op (nocaster<T1> ,nocaster<T2>);

My main objection to this is that I am pretty sure that a quantity/units library that does not do implicit unit conversion is a *lot* easier to implement than one that does. And it's hard for me to believe that a library that does automatic unit conversion doesn't have inside of it a simpler non-automatic unit conversion library. So implementing explicit unit conversion on top of an implicit conversion library seems, well, backwards. Deane

"Andy Little" <andy@servocomm.freeserve.co.uk> writes:

For addition you would need to do this:

nocast(a) + nocast(b);

for multiplication

nocast(a) * nocast(b);

Seems like one should be enough to prevent promotion and implicit combinations: nocast(a) * b

You could make this a general purpose utility:

template <typename T> struct no_caster{ T t; /*...*/ };

Alright, now you've gone too far. The name is taken. http://www.fender.com/products/search.php?partno=0150302867

template <typename T1, typename T2> typename boost:enable_if< boost::is_same<T1, T2>,T1

...

::type

operator Op (nocaster<T1> ,nocaster<T2>);

You might do it with expression templates to get: x [strict]= y + z * b; Or just encode the restriction in the type of x. -- Dave Abrahams Boost Consulting www.boost-consulting.com

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 tags". 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@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------