🚀 go-pugleaf

>>>>> "RP" == Robert Payne <rpayne@rainbow.rmii.com> writes:

 RP> Why has C++ stayed with the weak typedef?  It has always seemed to
 RP> me that it should provide a new type and not just a synomym.

C++ /has/ a mechanism for creating new types: `class'.
`typedef' is just a fancy `#define'--and I think it's clear from K&R that
that's all it was intended to be.

[ 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.
]

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: rpayne@rainbow.rmii.com (Robert Payne) writes:

: >Why has C++ stayed with the weak typedef?  It has always seemed to
: ><snip>

: 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.

I would even be happy just to see a compile time warning issued, unless
of course, the types were really incompatible.  I just feel that if
we are going to the trouble of creating abstract types, the least 
the compiler should do is issue a warning when we assign something
of cat_t to a dog_t entity even if the underlying type is 
indigenous and compatible. 

Cheers,

--
Robert Payne 

[ 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
]

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 
]

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 
]

In article <4g62li$kuh@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> 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.
>
>I don't remember that issue ever being brought up in the C++
>committee.

The final comment of the Swedish Committee Draft Ballot response was
a recommendation to look closer at this issue in the next round of
standardization.  The suggested syntax was

	explicit typedef int length;

Note the use of keyword explicit to distinguish it from the current
typedef.

Dag Bruck
Swedish Head of Delegation, ISO SC22/WG21

-- 
Dynasim AB                            Phone:  +46 46 182500
Research Park Ideon                   Fax:    +46 46 129879
S-223 70 Lund                         E-mail: Dag@Dynasim.se
Sweden                                URL:    http://www.dynasim.se


[ 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
]