In article <326bjh$psv@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
]Not correct. Look up the overloading rules. There is a standard conversion
]from every arithmetic type to every other arithmetic type. A long can
]be converted to an int or to a bool, so this is ambiguous. (Well, you
]can't look up the rules for bool, but it is treated similarly to, for
]example, short -- just another arithmetic type smaller** than int.)
]---
]Steve Clamage, stephen.clamage@eng.sun.com
]
]

Oops, sorry...that's what I get for not verifying my answers.  I was aware
of promotions being preferable and let that info cloud my thinking.  Of course,
I would have figured it out when I got the ambiguous error from my
compiler ;-)  Thanks for correcting me.

Stephen Gevers
sg3235@shelob.sbc.com

>>>>> Steve Clamage <clamage@Eng.Sun.COM> writes:

> The C++ Committee has added a true boolean type to the language. (But it
> may be a while before widely-available compilers implement it.)

Well, g++ 2.6.0 does.

Jason

In article Io0@netcom.com, rfg@netcom.com (Ronald F. Guilmette) writes:
>>
>>> My question is: is the pre-processor required to handle booleans?
>>
>>No.
>>
>>>     #if true
>>
>>This becomes '#if 0', unless true is a macro.
>
>Apparently, what Jason is saying is that the (new) built-in literals
>`true' and `false' have no special significance to the preprocessor.

That's right. The preprocessor has its own language, which isn't C or C++.
It doesn't know about C or C++ types or keywords. It can do integer
arithmetic, but the only type it knows about is an integer type, which
need not correspond exactly to any C or C++ type in the implementation.
It can evaluate logical expressions, but does not predefine 'true' or
'false' (or 'NULL' or any other symbolic constant).


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

In article jt1@ritz.cec.wustl.edu, jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut) writes:
>In article <Cu7xDE.1HCn@hawnews.watson.ibm.com>,
>Kevin Cooney  <cooney@vnet.ibm.com> wrote:
>:> Overloading works.
>:>
>:>  void f(int);
>:>  void f(bool); // only works if `bool' is not the same type as `int'.
>:
>:Ah, but if I then did the following:
>:
>: f( 'a' );
>: f( (long)1 );
>:
>:Would either of those be ambigious?  If so, then who would overload
>:on an int and a bool?  If not, which would be called?
>
>char promotes to int, so f('a') calls f(int)

Correct. Promotions are preferred over standard conversions. There is a
promotion from each of bool, char, and short to int (with the usual
caveats about whether an unsigned short or char fits in an int).

>and long doesn't promote to either
>int or bool so it's undefined (not ambiguous).

Not correct. Look up the overloading rules. There is a standard conversion
from every arithmetic type to every other arithmetic type. A long can
be converted to an int or to a bool, so this is ambiguous. (Well, you
can't look up the rules for bool, but it is treated similarly to, for
example, short -- just another arithmetic type smaller** than int.)


BTW, thanks to whoever posted this example. It is one case where a program
using an enum for bool will break when converting to the built-in bool.
There is no implicit conversion to an enum. So if bool is an enum, the
above code is unambiguous. When bool is a built-in, f(1L) becomes ambiguous. :-(
---
Steve Clamage, stephen.clamage@eng.sun.com

In article 1HHn@hawnews.watson.ibm.com, Kevin Cooney <cooney@vnet.ibm.com> writes:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: Making them into enums would tend to break code and in any event
>: require the use of casts. There is no implicit cast to an enum
>: type. We expect (in C and C++) to be able to use arithmetic on boolean
>: and character types and not need to cast back the result. When bool and
>: wchar_t are built-in arithmetic types this is true. If they are merely
>: prefined enum types it is not true.
>
>I'm not familiar with the proposal, but how is it better than the
>following:
>
>typedef int bool;
>const bool True( 1 );
>const bool False( 0 );

I don't know what you mean by "the proposal".

The C++ Committee has added a true boolean type to the language. (But it
may be a while before widely-available compilers implement it.)

Recall that a typedef only creates an alternative spelling for an
existing type; it does not create a new type. Your example is exactly
equivalent to
 const int True(1);
 const int False(0);
You can't tell bool's from int's anywhere in a program, and in particular
you cannot overload on the boolean type (under the old rules).

Programmers have tried creating a Boolean class, but that approach
collapses under its own weight. It really is unworkable.

Programmers have also made a boolen enum type, which does allow overloading
and detection of type errors, but creates new problems as above.

>Also, will operator==() still return an int?  Will if() still expect
>an int?  What would "True == 5" evaluate to in the proposal (if it is
>even legal)?  Would "int i = True" be legal?  "bool t = 1"?  "bool t =
>5"?

The relational and conditional expressions now all use bool. But bool is
an integral type with automatic conversion to and from all scalar types.
Any existing program which does not invent a boolean type should continue
to work unchanged under the new rules. Programs which create a boolean
type spelled "bool" will need some modification, as will any program which
has any identifier spelled "bool", "true", or "false". (These are now
reserved words, spelled in lower-case.)

Existing programs which create a boolean type not using "bool", "true",
or "false" will probably continue to work unchanged.
---
Steve Clamage, stephen.clamage@eng.sun.com