🚀 go-pugleaf

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

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

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

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

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

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.

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

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