In article <1995Jun28.104215.1324@ittpub> wil@ittpub.nl (Wil Evers)
writes:

|> In article <3sm8dm$244@gabi.gabi-soft.fr> kanze@gabi-soft.fr (J. Kanze)
|> writes:
|> > Wil Evers (wil@ittpub.nl) wrote:
|> > |> In article <3sbml2$2t9@gabi.gabi-soft.fr> James Kanze
|> > |> (kanze@gabi-soft.fr) writes:
|> > |> > Barry Margolin (barmar@nic.near.net) wrote:
|> > |> > |> In article <1995Jun19.094915.1294@ittpub> wil@ittpub.nl (Wil
|> Evers)
|> > |> writes:
|> > |> > |> >It may be that I'm not used to the built-in bool yet, but to
|> me, the
|> > |> fact
|> > |> > |> >that f(x == y) now calls f(bool) rather than f(int) is more
|> like a
|> > |> > |> >pitfall.
|> > |> >
|> > |> > |> While it is definitely an incompatibility with C and earlier
|> C++, I
|> > |> don't
|> > |> > |> see how it could be considered a pitfall.  Intuitively,
|> comparison
|> > |> > |> operators return logical results rather than numerical ones, so
|> why
|> > |> would
|> > |> > |> it be wrong for this to call the bool version of the overloaded
|> > |> function?
|> > |> >
|> > |> > Actually, there is no incompatibility with C.  In C, there is no
|> > |> > function overloading, so the problem doesn't exist.  If you have
|> defined
|> > |> > f(int) (and not f(bool)), then f(int) will be called.
|> >
|> > |> Come on, James! Of course, the incompatibility is in what the
|> comparison
|> > |> operators return (bool in C++, int in C), and as a result of that,
|> the
|> > |> overloading resolution is different from what some people might
|> expect.
|> >
|> > [snip]
|> >
|> > In the case of existing C++ code, it is true that there may be some code
|> > broken.  I think, however, that any code which is broken actually
|> > deserves to be broken.  Personally, I would have gone for *not* having
|> > the implicit conversions, so that it would be broken at compile time.
|> > The problem is: this would break the C compatibility, and since we
|> > assume that C++ programmers never write bad code... :-)

For the third time, my statement was with regards to C compatibility,
nothing else:

|> Here's an example:

|> 1. Someone defined a type (enum or class) bool.
|> 2. There are two f's, f(int) and f(bool).

This is illegal in C, so the rest is irrelevant to my argument.

|> 3. Someone else involved in some other part of the project calls f(x ==
|> y), knowing f(int) is called. Note that this call contains no reference to
|> the bool type.
|> 4. A new standard-conforming compiler is used. It complains about bool now
|> being a built-in type. The user-defined bool type is removed, and f(bool)
|> is examined and possibly adapted for the built-in bool.
|> 5. Unexpectedly, f(x == y) now calls f(bool) instead of f(int).

|> Why does such code *deserve* to be broken?

Because if there is a boolean type (user defined or built-in), then
calling f( x == y ) and expecting to get int (rather than bool) is a
perfect example of horrible design.  I cannot believe that anyone
actually does this intentionally.  (On the other hand, it is almost
certain that it regularly occurs accidentally, because the caller
forgot to cast x==y.  In this case, the programmer will probably be
happy that he is finally calling the function that he meant to call in
the first place.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <3sbml2$2t9@gabi.gabi-soft.fr> James Kanze
(kanze@gabi-soft.fr) writes:
> Barry Margolin (barmar@nic.near.net) wrote:
> |> In article <1995Jun19.094915.1294@ittpub> wil@ittpub.nl (Wil Evers)
writes:
> |> >It may be that I'm not used to the built-in bool yet, but to me, the
fact
> |> >that f(x == y) now calls f(bool) rather than f(int) is more like a
> |> >pitfall.
>
> |> While it is definitely an incompatibility with C and earlier C++, I
don't
> |> see how it could be considered a pitfall.  Intuitively, comparison
> |> operators return logical results rather than numerical ones, so why
would
> |> it be wrong for this to call the bool version of the overloaded
function?
>
> Actually, there is no incompatibility with C.  In C, there is no
> function overloading, so the problem doesn't exist.  If you have defined
> f(int) (and not f(bool)), then f(int) will be called.
> --

Come on, James! Of course, the incompatibility is in what the comparison
operators return (bool in C++, int in C), and as a result of that, the
overloading resolution is different from what some people might expect.

- Wil

Wil Evers (wil@ittpub.nl) wrote:
|> In article <3sbml2$2t9@gabi.gabi-soft.fr> James Kanze
|> (kanze@gabi-soft.fr) writes:
|> > Barry Margolin (barmar@nic.near.net) wrote:
|> > |> In article <1995Jun19.094915.1294@ittpub> wil@ittpub.nl (Wil Evers)
|> writes:
|> > |> >It may be that I'm not used to the built-in bool yet, but to me, the
|> fact
|> > |> >that f(x == y) now calls f(bool) rather than f(int) is more like a
|> > |> >pitfall.
|> >
|> > |> While it is definitely an incompatibility with C and earlier C++, I
|> don't
|> > |> see how it could be considered a pitfall.  Intuitively, comparison
|> > |> operators return logical results rather than numerical ones, so why
|> would
|> > |> it be wrong for this to call the bool version of the overloaded
|> function?
|> >
|> > Actually, there is no incompatibility with C.  In C, there is no
|> > function overloading, so the problem doesn't exist.  If you have defined
|> > f(int) (and not f(bool)), then f(int) will be called.

|> Come on, James! Of course, the incompatibility is in what the comparison
|> operators return (bool in C++, int in C), and as a result of that, the
|> overloading resolution is different from what some people might expect.

Reread what I wrote.  I said that there was no incompatibility with C.
In C, you simply cannot overload functions, so the *only* compatible
function would be f( int ).  Since the bool type silently converts to
int, the same function would be called as in C.

In the case of existing C++ code, it is true that there may be some code
broken.  I think, however, that any code which is broken actually
deserves to be broken.  Personally, I would have gone for *not* having
the implicit conversions, so that it would be broken at compile time.
The problem is: this would break the C compatibility, and since we
assume that C++ programmers never write bad code... :-)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

Barry Margolin (barmar@nic.near.net) wrote:
|> In article <1995Jun19.094915.1294@ittpub> wil@ittpub.nl (Wil Evers) writes:
|> >It may be that I'm not used to the built-in bool yet, but to me, the fact
|> >that f(x == y) now calls f(bool) rather than f(int) is more like a
|> >pitfall.

|> While it is definitely an incompatibility with C and earlier C++, I don't
|> see how it could be considered a pitfall.  Intuitively, comparison
|> operators return logical results rather than numerical ones, so why would
|> it be wrong for this to call the bool version of the overloaded function?

Actually, there is no incompatibility with C.  In C, there is no
function overloading, so the problem doesn't exist.  If you have defined
f(int) (and not f(bool)), then f(int) will be called.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

In article <9516901.8626@mulga.cs.mu.OZ.AU> Fergus Henderson
(fjh@cs.mu.oz.au) writes:
> wil@ittpub.nl (Wil Evers) writes:
>
> >I guess I'm missing something. If I say
> >
> >class bool {
> > char b;
> >public :
> > bool(int i = 0) : c(i != 0) { }
> > bool& operator=(int i) { c = i != 0; return *this; }
> > operator int() const { return b; }
> >};
> >
> >static const bool false(0);
> >static const bool true(1);
> >
> >this would allow me to overload on bool, at least explicitly. What
> >pitfalls do I get?
>
> The main pitfall is that if I write
>
>  void f(bool);
>  void f(int);
>  ...
>  f(x == y);
>
> it will call `f(int)' rather than `f(bool)'.
>

It may be that I'm not used to the built-in bool yet, but to me, the fact
that f(x == y) now calls f(bool) rather than f(int) is more like a
pitfall. And I suspect that many people with experience in C and pre-WP
C++ would be equally surprised.

- Wil

In article 1294@ittpub, wil@ittpub.nl (Wil Evers) writes:
>
>It may be that I'm not used to the built-in bool yet, but to me, the fact
>that f(x == y) now calls f(bool) rather than f(int) is more like a
>pitfall. And I suspect that many people with experience in C and pre-WP
>C++ would be equally surprised.

Why? Hardly any existing code will be affected:

1. If the code doesn't use bool, the bool result of comparisons will
be silently promoted to int, the same as always. You won't suddenly
get a different overload resolution, since there won't be any overloads
on type bool unless you add one explicitly.

2. If the code typedef's bool to be an integer type, the results will
probably be the same. Exception: you overload on the underlying typedef
instead of on bool, but code like that deserves to be broken.

3. If the code uses an enum type for bool, existing code will
continue to work as always, once the enum definition is removed.
Exception: sizeof(bool) may be different from the enum.

If you start using type bool, I hope that you will have read a
description of the type so you know what will happen when you use it.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <1995Jun19.094915.1294@ittpub> wil@ittpub.nl (Wil Evers) writes:
>It may be that I'm not used to the built-in bool yet, but to me, the fact
>that f(x == y) now calls f(bool) rather than f(int) is more like a
>pitfall.

While it is definitely an incompatibility with C and earlier C++, I don't
see how it could be considered a pitfall.  Intuitively, comparison
operators return logical results rather than numerical ones, so why would
it be wrong for this to call the bool version of the overloaded function?
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@{bbnplanet.com,near.net,nic.near.net}
Phone (617) 873-3126 - Fax (617) 873-5124

In article <3s4530$l46@engnews2.Eng.Sun.COM> Steve Clamage
(stephen.clamage@eng.sun.com) writes:
> In article 1294@ittpub, wil@ittpub.nl (Wil Evers) writes:
> >
> >It may be that I'm not used to the built-in bool yet, but to me, the
fact
> >that f(x == y) now calls f(bool) rather than f(int) is more like a
> >pitfall. And I suspect that many people with experience in C and pre-WP
> >C++ would be equally surprised.
>
> Why? Hardly any existing code will be affected:
>
> 1. If the code doesn't use bool, the bool result of comparisons will
> be silently promoted to int, the same as always. You won't suddenly
> get a different overload resolution, since there won't be any overloads
> on type bool unless you add one explicitly.
>
> 2. If the code typedef's bool to be an integer type, the results will
> probably be the same. Exception: you overload on the underlying typedef
> instead of on bool, but code like that deserves to be broken.
>
> 3. If the code uses an enum type for bool, existing code will
> continue to work as always, once the enum definition is removed.
> Exception: sizeof(bool) may be different from the enum.

But 4. If the code uses a bool class, which is removed because bool is now
a built-in type, the resolution of f(x == y) changes from f(int) to
f(bool).

> If you start using type bool, I hope that you will have read a
> description of the type so you know what will happen when you use it.

The expression f(x == y) doesn't have the word bool in it, so bool is used
without anyone asking for it. That's one of the reasons why the committee
shouldn't have added any built-in types to the language: you get them for
free, like it or not, and they change the meaning of existing code.

> ---
> Steve Clamage, stephen.clamage@eng.sun.com

- Wil

clamage@Eng.Sun.COM (Steve Clamage) writes:

>I'm really at a loss to understand the quibbling about the name wchar_t,
>given that it is already part of C.

I think it is simply because wchar_t is such an ugly name, when there was
an elegant and natural alternative available!

>If the C++ committee picked a different
>type name, we would undoubtedly see at least as many complaints about
>that:

You may well be right - but wchar_t is still ugly.
And I think the defence against those complaints would be
stronger.

>"Why invent a new name when one already exists? It just causes
>confusion to have two names for the same thing!"

The response to that could be:

 "We chose `long char' because that was the _right_ choice.
  We included the typedef `wchar_t' because it was needed
  for backwards compatibility.  Yes, we know that having
  two names for the same thing can cause confusion.
  But making `wchar_t' a builtin type would be confusing too,
  since the `_t' suffix is normally used for typedefs, not keywords.
  The name `long char' is a much more natural and elegant choice
  for a builitin type."

I think that is much a stronger defence than

 "We don't understand why so many people complain about wchar_t -
  it's only a name!"

:-)

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh

wil@ittpub.nl (Wil Evers) writes:

>I guess I'm missing something. If I say
>
>class bool {
> char b;
>public :
> bool(int i = 0) : c(i != 0) { }
> bool& operator=(int i) { c = i != 0; return *this; }
> operator int() const { return b; }
>};
>
>static const bool false(0);
>static const bool true(1);
>
>this would allow me to overload on bool, at least explicitly. What
>pitfalls do I get?

The main pitfall is that if I write

 void f(bool);
 void f(int);
 ...
 f(x == y);

it will call `f(int)' rather than `f(bool)'.

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh

In article <3rllch$pcv@news.erinet.com> Paul J. Ste. Marie,
pstemari@well.sf.ca.us, pstemari@erinet.com writes:
> In article <3rkfa0$sg0@engnews1.eng.sun.com>,
>    clamage@Eng.Sun.COM (Steve Clamage) wrote:
> :Your compiler is wrong. The overload-resolution rules in the ARM
> :and in the draft standard are different in detail, but agree on
> :this:
> :If one conversion sequence involves a user-defined conversion
> :only, and the other requires a user-defined conversion followed by
> :a promotion, neither is preferred over the other.
>
> Not always:
> [over.ics.rank] 13.3.3.2 Ranking implicit conversion sequences
> [snip]
> User defined conversion sequence U1 is a better conversion sequence
> than another user defined conversion sequence U2 if they contain
> the same user defined conversion operator or constructor and if the
> second standard conversion sequence of U1 is better than the second
> standard conversion sequence of U2.
>
>  --Paul J. Ste. Marie, pstemari@well.sf.ca.us, pstemari@erinet.com
>

So, getting back to the example that triggered Steve's remark (a class
bool instead of the built-in bool type):

class bool {
 char b;
public :
 bool(int i = 0) : b(i != 0) { }
 bool& operator=(int i) { b = i != 0; return *this; }
 operator int() const { return b; }
};

bool b;
void f(int);
void f(double);
..
f(b);  // ambiguous??

doesn't this mean the f(b) call is non-ambiguous, since:

- f(b) resolving to f(int): user defined conversion followed by 'No
conversion required' (rank of second standard conversion: Exact Match)
- f(b) resolving to f(double): same user defined conversion followed by
'Floating-integral conversion' (rank of second standard conversion:
Conversion)

and Exact Match is better than Conversion?

If the answer is no, where in the standard is the rule that says neither
is preferred over the other? I couldn't find it.

- Wil

In article 1271@ittpub, wil@ittpub.nl (Wil Evers) writes:
>In article <3r9rip$4uq@engnews1.eng.sun.com>  writes:

>> >class bool {
>> > char b;
>> >public :
>> > bool(int i = 0) : b(i != 0) { }
>> > bool& operator=(int i) { b = i != 0; return *this; }
>> > operator int() const { return b; }
>> >};

>> You have many opportunities for ambiguities. For example:
>>  bool b;
>>  void f(int);
>>  void f(double);
>>  ...
>>  f(b); // ambiguous


>The vintage compiler I use resolves this call to f(int), I think because
>f(int) requires only a user-defined conversion whilst f(double) requires
>an additional promotion from int to double. Are you saying that, supposing
>bool is not a keyword, a conforming compiler must flag f(b) as ambiguous?

Your compiler is wrong. The overload-resolution rules in the ARM and in
the draft standard are different in detail, but agree on this: If one
conversion sequence involves a user-defined conversion only, and the
other requires a user-defined conversion followed by a promotion, neither
is preferred over the other.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3rkfa0$sg0@engnews1.eng.sun.com>,
   clamage@Eng.Sun.COM (Steve Clamage) wrote:
:Your compiler is wrong. The overload-resolution rules in the ARM
:and in the draft standard are different in detail, but agree on
:this:
:If one conversion sequence involves a user-defined conversion
:only, and the other requires a user-defined conversion followed by
:a promotion, neither is preferred over the other.

Not always:

[over.ics.rank] 13.3.3.2 Ranking implicit conversion sequences
 [...]
Standard conversion sequence S1 is a better conversion sequence
than standard conversion sequence S2 if S1 is a proper subsequence
of S2, or, if not that,
 [...]
User   defined conversion sequence U1 is a better conversion sequence
than another user   defined conversion sequence U2 if they contain
the same user   defined conversion operator or constructor and if the
second standard conversion sequence of U1 is better than the second
standard conversion sequence of U2.

 --Paul J. Ste. Marie, pstemari@well.sf.ca.us, pstemari@erinet.com

Contact your Senators today to oppose the Comunications Decency Act
(S.652, Title IV)!

In article <3r9rip$4uq@engnews1.eng.sun.com>  writes:
> In article 1262@ittpub, wil@ittpub.nl (Wil Evers) writes:
>
> >In article <3r4f57$p0l@engnews2.Eng.Sun.COM>  writes:
> >> In article 1254@ittpub, wil@ittpub.nl (Wil Evers) writes:
>
> >> >Sure, we need to be able to overload on wchar_t (and bool). But why
did
> >> >the standards comittee decide to make wchar_t and bool built-in
types?
> >> >Wouldn't it have been better to provide them as classes?
>
> >> You cannot get the desired automatic type conversions and also avoid
> >> ambiguities if you make these classes. If you actually go through the
> >> exercise of trying to create a usable boolean (for example) class,
you will
> >> see what I mean. I know of many people who have tried. Without
exception,
> >> they gave up and went back to using either an enum or a typedef for a
> >> boolean type.
>
> >I guess I'm missing something. If I say
>
> >class bool {
> > char b;
> >public :
> > bool(int i = 0) : b(i != 0) { }
> > bool& operator=(int i) { b = i != 0; return *this; }
> > operator int() const { return b; }
> >};
>
> You have many opportunities for ambiguities. For example:
>  bool b;
>  void f(int);
>  void f(double);
>  ...
>  f(b); // ambiguous
>

The vintage compiler I use resolves this call to f(int), I think because
f(int) requires only a user-defined conversion whilst f(double) requires
an additional promotion from int to double. Are you saying that, supposing
bool is not a keyword, a conforming compiler must flag f(b) as ambiguous?

- Wil

In article 1262@ittpub, wil@ittpub.nl (Wil Evers) writes:

>In article <3r4f57$p0l@engnews2.Eng.Sun.COM>  writes:
>> In article 1254@ittpub, wil@ittpub.nl (Wil Evers) writes:

>> >Sure, we need to be able to overload on wchar_t (and bool). But why did
>> >the standards comittee decide to make wchar_t and bool built-in types?
>> >Wouldn't it have been better to provide them as classes?

>> You cannot get the desired automatic type conversions and also avoid
>> ambiguities if you make these classes. If you actually go through the
>> exercise of trying to create a usable boolean (for example) class, you will
>> see what I mean. I know of many people who have tried. Without exception,
>> they gave up and went back to using either an enum or a typedef for a
>> boolean type.

>I guess I'm missing something. If I say

>class bool {
> char b;
>public :
> bool(int i = 0) : c(i != 0) { }
> bool& operator=(int i) { c = i != 0; return *this; }
> operator int() const { return b; }
>};

You have many opportunities for ambiguities. For example:
 bool b;
 void f(int);
 void f(double);
 ...
 f(b); // ambiguous

If instead you use an enum for type bool, you don't get the ambiguities,
but you require explict casts to bool.

As an intrinsic type, you get overloading, don't require casts, and don't
get new ambiguities. Further, the comparison operators return a bool and
the 'if', 'for' and 'while' clauses take a bool. You could not allow that
unless bool were not reserved.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3r5gul$6ou@hermes.synopsys.com>, jbuck@synopsys.com (Joe Buck) writes:
|> clamage@Eng.Sun.COM writes:
|> >I'm really at a loss to understand the quibbling about the name wchar_t,
|> >given that it is already part of C.
|>
|> The problem is that there was an extremely natural choice: we have
|> int and long int, double and long double, why not have char and long char?

I agree with you. Is there any chance to make the proposed change
in the WP?

--
+==============================|==============================+
| Dr. Hartmut Kocher           |                              |
| Senior Technical Consultant  | All opinions expressed here  |
| Rational GmbH                | are my own.                  |
| Rosenstrasse 7               |                              |
| 82049 Pullach im Isartal     | I know you guessed it,       |
| Germany                      | but it keeps my lawyer happy.|
| Email: kocher@lts.sel.alcatel.de                            |
+==============================|==============================+

clamage@Eng.Sun.COM writes:
>I'm really at a loss to understand the quibbling about the name wchar_t,
>given that it is already part of C.

C compatibility would have been maintained equally well by introducing
"long char" and having

typedef long char wchar_t;

for compatibility.  wchar_t would now be a typedef in both languages,
rather than a typedef in one and a keyword in the other.

> If the C++ committee picked a different
>type name, we would undoubtedly see at least as many complaints about
>that: "Why invent a new name when one already exists? It just causes
>confusion to have two names for the same thing!"

The problem is that there was an extremely natural choice: we have
int and long int, double and long double, why not have char and long char?

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

In article <3r4f57$p0l@engnews2.Eng.Sun.COM>  writes:
> In article 1254@ittpub, wil@ittpub.nl (Wil Evers) writes:
> >
> >Sure, we need to be able to overload on wchar_t (and bool). But why did
> >the standards comittee decide to make wchar_t and bool built-in types?
> >Wouldn't it have been better to provide them as classes?

> You cannot get the desired automatic type conversions and also avoid
> ambiguities if you make these classes. If you actually go through the
> exercise of trying to create a usable boolean (for example) class, you
will
> see what I mean. I know of many people who have tried. Without
exception,
> they gave up and went back to using either an enum or a typedef for a
> boolean type.

I guess I'm missing something. If I say

class bool {
 char b;
public :
 bool(int i = 0) : c(i != 0) { }
 bool& operator=(int i) { c = i != 0; return *this; }
 operator int() const { return b; }
};

static const bool false(0);
static const bool true(1);

this would allow me to overload on bool, at least explicitly. What
pitfalls do I get?

> Apart from that, class machinery is a pretty elaborate way to get small
> integer constants (bool) or a range of integer constants (wchar_t).

According to the standard, C++ now has 73 reserved words. That's a lot.
Given C++'s objectives, most of them couldn't be avoided. But some could,
and I think bool is one of these.
The standard contains quite a few examples of classes that exist only for
overloading purposes, like the (empty) nothrow structure used to overload
operator new().

 > I'm really at a loss to understand the quibbling about the name
wchar_t,
> given that it is already part of C. If the C++ committee picked a
different
> type name, we would undoubtedly see at least as many complaints about
> that: "Why invent a new name when one already exists? It just causes
> confusion to have two names for the same thing!"
> ---

Agreed.

> Steve Clamage, stephen.clamage@eng.sun.com
>

- Wil

In article <3qvc17$co0@offas_dike.sbil.co.uk>  writes:
>
> [snippet]
>
> This is one of those historical warts that, I am afraid, will not be
changed
> any time soon (if ever).
>
> Going back in time, the C Committee decided to make the wide character
> type a typedef rather than a built-in type.  The reason was that wchar_t
> in C was not intended to be a *distinct* type, but merely a synonym for
> one of the existing integral types.  Given that it was merely a synonym,
> the Committee saw no point in introducing a new *language* type: a
typedef
> was sufficient.
>
> Now, this was clearly *insufficient* for C++, because a C++ user would
> want the ability to overload on wchar_t, which you could not do if
wchar_t
> was merely a synonym for one of the other existing types.  So, the C++
> Committee made wchar_t a built-in type.  In some ways, this is a wart,
> since things ending in '*_t' LOOK LIKE typedefs.  However, it has long
> been the policy of C++ to avoid gratuitous incompatibilities with C, and
> so it made sense simply to make wchar_t a built-in type and be done with
> it.
>
> ---
> Marc Shepherd
> Salomon Brothers Inc
> shepherd@schubert.sbi.com The opinions I express are no one's but
mine!

Sure, we need to be able to overload on wchar_t (and bool). But why did
the standards comittee decide to make wchar_t and bool built-in types?
Wouldn't it have been better to provide them as classes, like (assuming we
can represent a wchar_t by an unsigned short):

class wchar_t {
 unsigned short c;
public :
 wchar_t(unsigned short c) : c(cc)
  { }
 operator unsigned short() const
  { return c; }
 wchar_t& operator=(unsigned short cc)
  { c = cc; return *this; }
};

or something? This way, the introduction of new keywords would have been
avoided and wchar_t would behave as a regular identifier. Any comments?

- Wil

In article 1254@ittpub, wil@ittpub.nl (Wil Evers) writes:
>
>Sure, we need to be able to overload on wchar_t (and bool). But why did
>the standards comittee decide to make wchar_t and bool built-in types?
>Wouldn't it have been better to provide them as classes, like (assuming we
>can represent a wchar_t by an unsigned short):

You cannot get the desired automatic type conversions and also avoid
ambiguities if you make these classes. If you actually go through the
exercise of trying to create a usable boolean (for example) class, you will
see what I mean. I know of many people who have tried. Without exception,
they gave up and went back to using either an enum or a typedef for a
boolean type.

Apart from that, class machinery is a pretty elaborate way to get small
integer constants (bool) or a range of integer constants (wchar_t).

I'm really at a loss to understand the quibbling about the name wchar_t,
given that it is already part of C. If the C++ committee picked a different
type name, we would undoubtedly see at least as many complaints about
that: "Why invent a new name when one already exists? It just causes
confusion to have two names for the same thing!"
---
Steve Clamage, stephen.clamage@eng.sun.com