Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: rpayne@rainbow.rmii.com (Robert Payne) writes:
:
: >Why has C++ stayed with the weak typedef?  It has always seemed to
: >me that it should provide a new type and not just a synomym.  Some
: >lints check for strong typing but I haven't found a compiler that
: >will enforce it.  I know this must have been debated at some point
: >but I didn't find it in a FAQ.  Could someone please enlighten me?
:
: If typedef were to create a new type, what operations would be allowed
: on the new type?
:
: I think that changing the meaning of `typedef' would be a bad idea.
: It might make sense to propose a new construct, say `newtypedef', that
: did something different, but C++ already has a way to create new types
: (`class'), and it is not at all clear that adding a new way would be
: worth the additional complexity.


I see two issues at odds here, and a desire to satisfy them both with one
construct.

One issue is type safety in function calls. You might have

 typedef double DOLLARS;
 typedef double INTEREST_RATE;

and want to define a function declared as

 DOLLARS PresentValue(DOLLARS futureValue,
  INTEREST_RATE rate, int YEARS);

that will keep the user from accidentally swapping the money and interest
arguments when coding a call to the function.

On the other hand, within functions that use these types, you might want
all the ordinary mathematical functions to apply as usual to the raw
values underneath. The function call has already guaranteed that the set
of arguments given has types that are meaningful given the function's
purpose. Now we want to take these arguments for what they really
are--doubles--and apply normal arithmetic to them with no headaches.


[ To submit articles: Try just posting with your newsreader.
        If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Harlan Messinger (gusty@clark.net) wrote:
: Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: : rpayne@rainbow.rmii.com (Robert Payne) writes:
: :
: : >Why has C++ stayed with the weak typedef?  It has always seemed to
: : >me that it should provide a new type and not just a synomym.  Some
: : >lints check for strong typing but I haven't found a compiler that
: : >will enforce it.  I know this must have been debated at some point
: : >but I didn't find it in a FAQ.  Could someone please enlighten me?
: :
: : If typedef were to create a new type, what operations would be allowed
: : on the new type?
: :
: : I think that changing the meaning of `typedef' would be a bad idea.
: : It might make sense to propose a new construct, say `newtypedef', that
: : did something different, but C++ already has a way to create new types
: : (`class'), and it is not at all clear that adding a new way would be
: : worth the additional complexity.

: I see two issues at odds here, and a desire to satisfy them both with one
: construct.

: One issue is type safety in function calls. You might have

:  typedef double DOLLARS;
:  typedef double INTEREST_RATE;

: and want to define a function declared as

:  DOLLARS PresentValue(DOLLARS futureValue,
:   INTEREST_RATE rate, int YEARS);

: that will keep the user from accidentally swapping the money and interest
: arguments when coding a call to the function.

: On the other hand, within functions that use these types, you might want
: all the ordinary mathematical functions to apply as usual to the raw
: values underneath. The function call has already guaranteed that the set
: of arguments given has types that are meaningful given the function's
: purpose. Now we want to take these arguments for what they really
: are--doubles--and apply normal arithmetic to them with no headaches.

Wow, I did just exactly this just yesterday.  I was having problems
keeping track of what numbers were in internal format, and which were
in external format, so I made two classes:

class externalValue {
    double v;
public:
    operator double() { return v; }
    explicit externalValue(double x) { v = x; }
    /* extra fns to read/write to files */
};

class internalValue {
    double v;
public:
    operator double() { return v; }
    explicit internalValue(double x) { v = x; }
};

This way functions and classes can define variables as external or internal,
but complicated formulas involving the numbers still work fine.

I then have a series of conversion functions:

internalValue toInternal(externalValue v) {
    return internalValue(3 * v - 4);
}

etc.  Works quite nicely.

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
>The disadvantage of "class" is that it creates a structure type. If you
>want to create a new arithmetic type, you can do that with "class", but
>you have to define all the arithmetic operators over again, using
>inlines. The Borland compiler, for one, will let you do that, but it
>will never generate code quite as efficient as it will for the built-in
>types, where it is happy to do arithmetic (addition and subtraction, at
>least) in whatever registers are most convenient.

This is a weakness in current implementations, and it is not inherent in
the C++ language (GNU C++ has some of the same weaknesses).  These
weaknesses *are* related to the complexity of the standard; due to the
sheer complexity and the large number of new features, most C++ compiler
implementers are struggling to get the front-end parsing and semantics
right and haven't devoted the same resources to optimization.

Because this is true, the very *worst* thing to do would be to extend the
language still more in the hope of getting better code generation.  It
would probably produce the opposite effect.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.    -- Vaclav Havel

[ To submit articles: Try just posting with your newsreader.
        If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

rpayne@rainbow.rmii.com (Robert Payne) writes:

>Why has C++ stayed with the weak typedef?  It has always seemed to
>me that it should provide a new type and not just a synomym.  Some
>lints check for strong typing but I haven't found a compiler that
>will enforce it.  I know this must have been debated at some point
>but I didn't find it in a FAQ.  Could someone please enlighten me?

I don't remember that issue ever being brought up in the C++
committee. The obvious argument against it is that it would
break too many existing programs. Whether the benefits would
outweigh the cost is debatable, but my feeling is that the
cost is too high.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

rpayne@rainbow.rmii.com (Robert Payne) writes:

>Why has C++ stayed with the weak typedef?  It has always seemed to
>me that it should provide a new type and not just a synomym.  Some
>lints check for strong typing but I haven't found a compiler that
>will enforce it.  I know this must have been debated at some point
>but I didn't find it in a FAQ.  Could someone please enlighten me?

If typedef were to create a new type, what operations would be allowed
on the new type?

I think that changing the meaning of `typedef' would be a bad idea.
It might make sense to propose a new construct, say `newtypedef', that
did something different, but C++ already has a way to create new types
(`class'), and it is not at all clear that adding a new way would be
worth the additional complexity.

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

The disadvantage of "class" is that it creates a structure type. If you
want to create a new arithmetic type, you can do that with "class", but
you have to define all the arithmetic operators over again, using
inlines. The Borland compiler, for one, will let you do that, but it
will never generate code quite as efficient as it will for the built-in
types, where it is happy to do arithmetic (addition and subtraction, at
least) in whatever registers are most convenient.

Perhaps we need a syntax like:

 class myint: public int;
 class specialint: public myint;

so a myint could be used where an int was expected, and a specialint
could be used where a myint was expected.

But as soon as we do that, people will want to specify valid ranges for
the types, a la Ada, which adds another whole level of complexity.

--

Ciao,
Paul D. DeRocco
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std.c++-request@ncar.ucar.edu
]