In article <3n6gpe$3ep@usenet.srv.cis.pitt.edu>,
Phillip G Maclean <pgmst+@pitt.edu> wrote:
>Inheriting Mass from type double is admittedly ONLY convenient.
>As has been noted classes can be written which will serve as the base
>class that I am interested in.
>
>My program uses a mix from different unit systems (eg MKS,eV,cm,Kg...)
>Routines use what ever units are natural for them to use.
>It would be great to exploit typesafety and maybe even define conversions
>between the systems and to do it CONVENIENTLY.  We all have better things
>to do than to implement this themselves.  Work must be done, right?
>
>Why shouldn't the language carry this burden?

 See Barton and Nackman for a template based technique
of enforcing dimensional correctness. I don't think this covers
differing units (eg Pounds vs. Kilograms) but I imagine this
can be done with the usual notions of conversion -- by fixing
an internal standard (e.g. the MKS system).

 A problem with this whole idea is that much physics
is an approximation and therefore physical laws are
often NOT dimensionally correct -- that is, you have to "cast away"
dimensions to do the calculations anyhow.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Inheriting Mass from type double is admittedly ONLY convenient.
As has been noted classes can be written which will serve as the base
class that I am interested in.

My program uses a mix from different unit systems (eg MKS,eV,cm,Kg...)
Routines use what ever units are natural for them to use.
It would be great to exploit typesafety and maybe even define conversions
between the systems and to do it CONVENIENTLY.  We all have better things
to do than to implement this themselves.  Work must be done, right?

Why shouldn't the language carry this burden?

Phillip MacLean
pgmst@pitt.edu

In article <3mv7jn$i0n@steel.interlog.com>,
Herb Sutter <herbs@interlog.com> wrote:
>In article <3m71je$gdu@usenet.srv.cis.pitt.edu>,
>   pgmst+@pitt.edu (Phillip G Maclean) wrote:
>>Note: Please email any response which is not directly relevant to this
>group.
>>
>>I would find it helpful to be able to inherit from type double.  I was
>>discouraged when I naively tried to inherit from built-in type
>>double and failed.  I am somewhat interested in why it failed (see note.)
>>I would like to know if it MUST fail and if not why not require, as
>>standard, that inheritance from built-in types succeed.  This would save
>>programmers the burden of writing classes that provide the functionality of
>>built-in's and it seems a logical way to get that functionality.
>>
>>In my case I would like to define classes displacement, mass, ... to have
>the
>>full functionality of type double plus whatever features I add.  Am I
>missing
>>something?
>
>Have you considered "has-a" (containment) or renaming (typedef) instead of
>"is-a" (public inheritance) or "is-implemented-in-terms-of" (private
>inheritance)?
>
>For example, if you want a class Mass that holds a mass value in some unit
>of measurement, I assume you want to encapsulate Mass-ness by adding member
>functions that let you operate on Mass objects (can't think of any examples
>right now), since that should be the reason you want it as a class.  In that
>case the class Mass would have a private member of type double to store the
>internal state (value), and would supply member functions to do the
>appropriate extra things you want to do with a Mass that you can't do with
>a double.
>

Yes.

>If you are not adding functionality and thus abstraction and you just want
>Mass to work like double with no extensions, then you should just "typedef
>double Mass".
>

I don't think that's right. What he mostly wants here is to _restrict_
functionality, ie. type safety. With typedefs you can do this:

typedef double Mass;
typedef double Length;

Mass m;
Length l = m;

BAD!!

--
Ian T Zimmerman            +-------------------------------------------+
P.O. Box 13445             I    With so many executioners available,   I
Berkeley, California 94712 I suicide is a really foolish thing to do.  I
USA  <itz@rahul.net>       +-------------------------------------------+

In article <3m71je$gdu@usenet.srv.cis.pitt.edu>,
   pgmst+@pitt.edu (Phillip G Maclean) wrote:
>Note: Please email any response which is not directly relevant to this
group.
>
>I would find it helpful to be able to inherit from type double.  I was
>discouraged when I naively tried to inherit from built-in type
>double and failed.  I am somewhat interested in why it failed (see note.)
>I would like to know if it MUST fail and if not why not require, as
>standard, that inheritance from built-in types succeed.  This would save
>programmers the burden of writing classes that provide the functionality of
>built-in's and it seems a logical way to get that functionality.
>
>In my case I would like to define classes displacement, mass, ... to have
the
>full functionality of type double plus whatever features I add.  Am I
missing
>something?

Have you considered "has-a" (containment) or renaming (typedef) instead of
"is-a" (public inheritance) or "is-implemented-in-terms-of" (private
inheritance)?

For example, if you want a class Mass that holds a mass value in some unit
of measurement, I assume you want to encapsulate Mass-ness by adding member
functions that let you operate on Mass objects (can't think of any examples
right now), since that should be the reason you want it as a class.  In that
case the class Mass would have a private member of type double to store the
internal state (value), and would supply member functions to do the
appropriate extra things you want to do with a Mass that you can't do with
a double.

If you are not adding functionality and thus abstraction and you just want
Mass to work like double with no extensions, then you should just "typedef
double Mass".


---
Herb Sutter             #include <std_disclaimer.h>
herbs@interlog.com      "Me?  Paranoid?  ... Uh, why do you ask?"

pgmst+@pitt.edu (Phillip G Maclean) writes:

>I would find it helpful to be able to inherit from type double.  I was
>discouraged when I naively tried to inherit from built-in type
>double and failed.  I am somewhat interested in why it failed (see note.)
>I would like to know if it MUST fail and if not why not require, as
>standard, that inheritance from built-in types succeed.

The C++ rule is that you can derive a class only from a class type.
Thus, you cannot derive a class from type double, for example.

It has been informally suggested that derivation be allowed from
built-in types, but no formal proposal (as far as I know) was
ever submitted to or considered by the C++ committee.
--
Steve Clamage, stephen.clamage@eng.sun.com

Note: Please email any response which is not directly relevant to this group.

I would find it helpful to be able to inherit from type double.  I was
discouraged when I naively tried to inherit from built-in type
double and failed.  I am somewhat interested in why it failed (see note.)
I would like to know if it MUST fail and if not why not require, as
standard, that inheritance from built-in types succeed.  This would save
programmers the burden of writing classes that provide the functionality of
built-in's and it seems a logical way to get that functionality.

In my case I would like to define classes displacement, mass, ... to have the
full functionality of type double plus whatever features I add.  Am I missing
something?


      Thank you,
      Phillip MacLean
      <pgmst@pitt.edu>