Topic: What!!! true and false not identifiers?
Author: dag@net.dynasim.se (Dag Bruck)
Date: 1995/08/04 Raw View
In article <NEWTNews.807452778.29822.Trebor@eagle.lute.qnet.com>,
Trebor A. Rude <trebor@en.ecn.purdue.edu> wrote:
>
>An alternitive that would allow both overloading and implicit type
>conversions is something like this:
>
>enum BOOLEAN { false, true };
>
>class bool {
> BOOLEAN value;
>public:
> // Put in type conversion, operators, etc.
>}
>
>Granted, it takes two identifiers, but I think it comes closest to
>implementing the type as the draft standard does (at least among
>what I've seen so far).
Yes but what does it do to overloading...
void f(int); // calls this one
void f(bool);
void f(BOOLEAN);
f( x < 3 );
You really want your bool type to be exactly the type returned
by the relational operators.
-- Dag Bruck
--
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
Author: wil@ittpub.nl (Wil Evers)
Date: 1995/08/04 Raw View
In article <fwv3ffkzm98.fsf@oculus.aifh.ed.ac.uk>
andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon) writes:
> I don't believe it! true and false are keywords, at least according to
> g++, which gets a parse error on this code.
>
> f() {
> int true = 0; // parse error
> }
>
> Why?
Believe it or not, but according to the draft ANSI/ISO standard, C++ now
has a built-in boolean type which uses the keywords 'bool', 'false' and
'true'. Regular readers of this newsgroup will tell you the introduction
of the built-in bool into the language is a highly controversial decision,
not only because many people think we don't need such a thing, but also
because the built-in bool has been substantially cluttered with
non-boolean operations for backward compatibility.
However, if I may say so, your example shows the built-in bool may have
some merit after all. Setting a variable named `true' to zero is asking
for trouble. Under the new rules, this is no longer possible.
- Wil
Author: andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon)
Date: 1995/08/04 Raw View
In article <3vo825$k9n@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve Clamage) writes:
> >I don't believe it! true and false are *keywords*, at least according to
>
> [explanation of bool introduction deleted]
That's not my point. My point is that true and false are *keywords*, not
identifiers. I want to know why.
A.
--
Andrew Fitzgibbon (Research Associate), andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University. +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
"Never say there is no way" -- me.
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1995/08/05 Raw View
andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon) writes:
>That's not my point. My point is that true and false are *keywords*, not
>identifiers. I want to know why.
If they are identifiers, they have to be defined somewhere. Where?
Pascal, for example, has the notion of "predefined identifiers". A
lot of the keywords in the language are not reserved. They are
predefined in a notional outer scope that encloses the entire program.
The number of reserved words is small. For better or worse, you can
provide your own definitions of the predefined identifiers.
procedure p;
var:
boolean, true, false: integer;
begin
...
false := true - boolean;
...
end;
Procedure p has local integer variables having the names of the
predefined boolean type and boolean constants. In practice, Pascal
programmers tend not to usurp the predefined identifiers; it's
too confusing.
C does not have the notion of the enclosing scope or predefined
identifiers, and the decision was made not to introduce it into C++.
Without this sort of language change, the boolean type would have to be
defined in a standard header. How do we integrate what amounts to a
user-defined type into the language? That is, if boolean is a typedef,
we can't overload functions on it. If it is an enum, we don't get
implicit conversions to boolean. If for balance we disallow
implicit conversion from boolean, we break all existing code.
Further, what is the result type of the relational operators? If
it remains int, we get some ludicrous results:
f(bool); // assume bool is not int
f(int);
...
f(true) // calls f(bool)
f(i>j) // calls f(int)
If relational operators return the boolean type defined only in a
header, we have a pretty strange situation. Effectively, you have
to include that header in every program, and the situation is
nearly equivalent to having made reserved words.
The solution chosen was to build the boolean type into the language
with reserved words. We get the following good effects:
- a standard boolean type with standard spellings and values.
- the ability to overload reliably on the boolean type with predictable
results.
- consistent results using boolean expressions. For example,
f(i>j) will call f(bool) if that overloaded function is declared.
You can test every boolean variable against 'true' or the value
1 safely, which is not now the case. (Previously, a "boolean"
variable could have a value not equal to either true or false.)
- automatic conversion among the numeric types to preserve most all
existing code.
- the ability to use simply and reliably a one-bit boolean bitfield
(no concerns about whether it is signed).
As with all design decisions, there are some drawbacks, mostly
in breaking some previously-valid code. But ANY solution adopted
would have broken SOME code. Adopting NO solution would have
left the current intolerable mess. The committee felt the
solution adopted was the best compromise, giving the most utility
and breaking the least amount of existing code.
One more thing: when the boolean type and constants are reserved
words, the compiler will tell you about misuses. If they could
be locally redefined, you could wind up with very subtle bugs
due to different definitions of the "same" type and "same"
constants in different parts of the program due to legacy code.
--
Steve Clamage, stephen.clamage@eng.sun.com
Author: andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon)
Date: 1995/08/02 Raw View
I don't believe it! true and false are keywords, at least according to
g++, which gets a parse error on this code.
f() {
int true = 0; // parse error
}
Why?
A.
--
Andrew Fitzgibbon (Research Associate), andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University. +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
"Never say there is no way" -- me.
Author: leshek@lexmark.com(Leshek Fiedorowicz)
Date: 1995/08/02 Raw View
In <fwv3ffkzm98.fsf@oculus.aifh.ed.ac.uk>, andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon) writes:
>
>I don't believe it! true and false are keywords..
or maybe just declared as <const> in some header file. In general it is highly
recommended to use <const> variables in place of <#defines> in C++.
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Leshek Fiedorowicz "Whatever I say it is just a gossip..." (Logan :-)
AIC / Lexmark - Printer Desktop Management Interface
leshek@lexmark.com Senior Computer Systems Engineer / Consultant
74170.2007@compuserve.com in Lexington KY, USA
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1995/08/02 Raw View
In article fsf@oculus.aifh.ed.ac.uk, andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon) writes:
>
>I don't believe it! true and false are keywords, at least according to
>g++, which gets a parse error on this code.
>
> f() {
> int true = 0; // parse error
> }
That is correct. C++ now has a built-in boolean type, and has added the
reserved words 'bool', 'true', and 'false'. Some compilers have already
implemented the boolean type. Eventually all compilers will.
For details of type bool, see the draft standard, available in postscript and
html on several ftp sites. Briefly: type bool has an implementation-defined
size, allows only the values 'true' and 'false'. 'true' converts implicitly in
expressions to the value 1, 'false' to 0. The value 0 can be converted
implicitly to bool and becomes 'false', any other value becomes 'true'.
Since bool is a distinct type, you can overload functions on type bool.
For compatibility with existing code during the transition period, you can
place something like the following in a project header file:
#ifdef NO_BOOL_TYPE
typedef int bool; // allows implicit conversions but not overloading
const bool false = 0;
const bool true = 1;
#endif
and then #define NO_BOOL_TYPE for compilers which do not yet support bool.
An alternative, which does not allow implicit conversions but which does
allow overloading on bool would be
enum bool { false, true };
---
Steve Clamage, stephen.clamage@eng.sun.com
Author: kuehl@uzwil (Dietmar Kuehl)
Date: 1995/08/02 Raw View
Hi,
Leshek Fiedorowicz (leshek@lexmark.com) wrote:
: In <fwv3ffkzm98.fsf@oculus.aifh.ed.ac.uk>, andrewfg@oculus.aifh.ed.ac.uk (Andrew Fitzgibbon) writes:
: >
: >I don't believe it! true and false are keywords..
:
: or maybe just declared as <const> in some header file. In general it is highly
: recommended to use <const> variables in place of <#defines> in C++.
According to the C++ Draft WP, 'bool' is a C++ built-in type with the
two values 'true' and 'false'. Beginning with gcc-2.6.? the type bool
is supported by gcc. You should be aware that there are more keywords
in C++ than in C. It is correct that some will of the introduced
keywords break existing code. Especially, the keywords introduced into
C++ after the ARM was released.
dk
--
http://www.informatik.uni-konstanz.de/~kuehl
dietmar.kuehl@uni-konstanz.de
I am a realistic optimist - that's why I appear to be slightly pessimistic
Author: leshek@lexmark.com(Leshek Fiedorowicz)
Date: 1995/08/02 Raw View
In <DCorpE.42I@lexmark.com>, leshek@lexmark.com(Leshek Fiedorowicz) writes:
>or maybe just declared as <const> in some header file. In general it is highly
>recommended to use <const> variables in place of <#defines> in C++.
>
Jarand is of course right saying (Jarand you don't mind me posting your mail message,
right :-):
"...
From: Jarand.Roynstrand
Date: 08-02-95 04:56:04 PM
Subject: Re: What!!! true and false not identifiers?
Hardly. If you re-read the original post you will se that he is definig a new
variable true local to the function in question. That would be perfectly
legal if true was a global <const>. (You may set up e.g. g++ to give a
warning on it though.)
The code fragment in question is only illegal if true is a key word.
jarand
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Leshek Fiedorowicz "Whatever I say it is just a gossip..." (Logan :-)
AIC / Lexmark - Printer Desktop Management Interface
leshek@lexmark.com Senior Computer Systems Engineer / Consultant
74170.2007@compuserve.com in Lexington KY, USA
Author: "Trebor A. Rude" <trebor@en.ecn.purdue.edu>
Date: 1995/08/03 Raw View
In Article<3vo825$k9n@engnews2.Eng.Sun.COM>, <clamage@Eng.Sun.COM> write:
> For compatibility with existing code during the transition period, you can
> place something like the following in a project header file:
>
> #ifdef NO_BOOL_TYPE
> typedef int bool; // allows implicit conversions but not overloading
> const bool false = 0;
> const bool true = 1;
> #endif
>
> and then #define NO_BOOL_TYPE for compilers which do not yet support bool.
> An alternative, which does not allow implicit conversions but which does
> allow overloading on bool would be
>
> enum bool { false, true };
>
> ---
> Steve Clamage, stephen.clamage@eng.sun.com
>
>
An alternitive that would allow both overloading and implicit type
conversions is something like this:
enum BOOLEAN { false, true };
class bool {
BOOLEAN value;
public:
// Put in type conversion, operators, etc.
}
Granted, it takes two identifiers, but I think it comes closest to
implementing the type as the draft standard does (at least among
what I've seen so far).
Trebor A. Rude
trebor@en.ecn.purdue.edu