🚀 go-pugleaf

In <4167na$nv9@engnews2.Eng.Sun.COM>, herbs@interlog.com (Herb Sutter) writes:
>Here's the point that's perhaps being missed: The problem which the built-in 
>type 'bool' (and the literals 'true' and 'false') fixed does not exist in the 
>preprocessor (no automatic conversions, etc.), so unless you can correct me 
>and point out a benefit to suddenly putting a type into the preproc, I'm 
>afraid I don't see your point.

Herb, since 'true' is a literal, I should be able to write 'true" as a constant in
both the preprocessor and in C++ itself.  The benefit is that you don't have
two or more multiple names for exactly the same thing.  And again, you do
NOT introduce a type in the preprocessor by allowing it to recognize a
literal.  Why does everybody keep talking about "types" when I am talking
about "literals"?  The strings '0' and 'a' but nobody worries that the
preprocessor needs to interpret '0' as a "type" of int and 'a' as a "type" of
char.  Nor does 'true' need to be interpreted as a "type" of bool.

A literal is a special symbol that the compiler recognizes as a constant.
The preprocessor handles some literals (such as numbers and characters),
but not others (such as floating point numbers).  I believe that the
'true' and 'false' literals SHOULD be recognized by the preprocessor
becuase they promote to intergral types and can therefore be used in a
constant integral expression.

I personally find it very annoying to use 'true' in one location and 'True'
or 'TRUE' or 'tRUe' somewhere else -- differing only in capitalization but
having the same intent and semantic definition.  This is absolutely (in my
opinion) unnecessary confusion that such a situation would engender.  And
it would ALSO tend to promote bugs.  The preprocessor would bitch if 'true'
were used, but the compiler would NOT bitch if 'True' were used because
of the standard promotion rules.

Michael Lee Finney


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mfinney@inmind.com writes:

>In <4167na$nv9@engnews2.Eng.Sun.COM>, herbs@interlog.com (Herb Sutter) writes:
>>Here's the point that's perhaps being missed: The problem which the built-in 
>>type 'bool' (and the literals 'true' and 'false') fixed does not exist in the 
>>preprocessor (no automatic conversions, etc.), so unless you can correct me 
>>and point out a benefit to suddenly putting a type into the preproc, I'm 
>>afraid I don't see your point.

>Herb, since 'true' is a literal, I should be able to write 'true" as a constant in
>both the preprocessor and in C++ itself.  The benefit is that you don't have
>two or more multiple names for exactly the same thing.  And again, you do
>NOT introduce a type in the preprocessor by allowing it to recognize a
>literal.  Why does everybody keep talking about "types" when I am talking
>about "literals"?  The strings '0' and 'a' but nobody worries that the
>preprocessor needs to interpret '0' as a "type" of int and 'a' as a "type" of
>char.

But that is not the case.

There are no types in the preprocessor, not even literal chars. Chars
and wide chars are treated as their integer values.  There are no enums,
pointers, or floating-point values. The result of any comparison is the
integer value 0 or 1.

If true and false were introduced into the preprocessor, they would 
have to be predefined to the preprocessor numbers 1 and 0. They would
then be the only prefined literals in the preprocessor. Why would this
be superior to just using 1 and 0 in your code, given that there are
no types to begin with? That is, IMHO 'true' gives no advantage
whatever over '1' in a preprocessor expression, since it cannot mean
anything different from '1', and since it must iteract with expressions
with integer (not boolean) values.

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

In <417kfc$1q3@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
>But that is not the case.
>
>There are no types in the preprocessor, not even literal chars. Chars
>and wide chars are treated as their integer values.  There are no enums,
>pointers, or floating-point values. The result of any comparison is the
>integer value 0 or 1.
>
>If true and false were introduced into the preprocessor, they would 
>have to be predefined to the preprocessor numbers 1 and 0.

Yes. So?  Why is that any different that treating 'a' as its integral value?
That is EXACTLY what I would expect.

> Why would this
>be superior to just using 1 and 0 in your code

Readablity.  The use of 'true' and 'false" as opposed to '1' and '0' when dealing
with logical issues is MUCH more readable.  I haven't used '1' and '0' in the
preprocessor for a logical condition since about my second day of writing C code
(which was a LONG time ago <g>).

Michael Lee Finney


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <416oev$71f@mujibur.inmind.com>,  <mfinney@inmind.com> wrote:
>
>I personally find it very annoying to use 'true' in one location and 'True'
>or 'TRUE' or 'tRUe' somewhere else -- differing only in capitalization but
>having the same intent and semantic definition.  This is absolutely (in my
>opinion) unnecessary confusion that such a situation would engender.  And
>it would ALSO tend to promote bugs.  The preprocessor would bitch if 'true'
>were used, but the compiler would NOT bitch if 'True' were used because
>of the standard promotion rules.
>

	Unfortunately, it's even worse than that.   The preprocessor will 
NOT complain about true.   This can cause some rather unpleasant surprises,
for example:

#define MC68000

#ifdef MC68000
#define BIGENDIAN true
#endif

#if BIGENDIAN
int main(int argc, char **argv)
{
  printf("Hello, world!\n);
  return 0;
}
#else
int main(int argc, char **argv)
{
  printf("Surprise!\n);
  return 1;
}
#endif

--
William E. Aitken 			    | Formal verification is the 
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
Who wants to use "true" or "false" in the preprocessor anyway?  What are
you going to do:  #if true ... ?

In setting compiler directives, what's so bad about 1 and 0 (they
generally tend to be somewhat isolated and the point should be clear
anyway):

#define qDebug 1
#define qUseOptimizations 0

and so on.

---------------------------
Brian T. Hill
bhil@strata3d.com
http://park.uvsc.edu/~bhil/



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:

>mfinney@inmind.com writes:
>>The benefit is that you don't have
>>two or more multiple names for exactly the same thing.  And again, you do
>>NOT introduce a type in the preprocessor by allowing it to recognize a
>>literal.  Why does everybody keep talking about "types" when I am talking
>>about "literals"?  The strings '0' and 'a' but nobody worries that the
>>preprocessor needs to interpret '0' as a "type" of int and 'a' as a "type" of
>>char.

Steve Clamage <clamage@Eng.Sun.COM> wrote:
>But that is not the case.
>
>There are no types in the preprocessor, not even literal chars. Chars
>and wide chars are treated as their integer values.  There are no enums,
>pointers, or floating-point values. The result of any comparison is the
>integer value 0 or 1.
>
>If true and false were introduced into the preprocessor, they would 
>have to be predefined to the preprocessor numbers 1 and 0. They would
>then be the only prefined literals in the preprocessor. Why would this
>be superior to just using 1 and 0 in your code, given that there are
>no types to begin with? That is, IMHO 'true' gives no advantage
>whatever over '1' in a preprocessor expression, since it cannot mean
>anything different from '1', and since it must iteract with expressions
>with integer (not boolean) values.

I'm not sure about this.  What about cases like this:


	#define DEBUG	false


	bool	debug = DEBUG;


	#if DEBUG
		// do debug stuff
	#endif /* DEBUG */


	if (DEBUG) {
		// do debug stuff
	}


	debug_message (DEBUG);		// what if overloaded with int?



This seems to indicate a need for "false" to be synonymous with "0" to
the preprocessor.  Automatic int to enum conversion (ugh) lets you use
"0" for all except the last case.  --Alan Char

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <419fk4$75b@news1.halcyon.com>, aitken@coho.halcyon.com (William E. Aitken) writes:
>	Unfortunately, it's even worse than that.   The preprocessor will 
>NOT complain about true.   This can cause some rather unpleasant surprises,

Ouch!  That makes it even MORE imperative that they fix the problem!
Nothing like breaking our code silently!  What they always try to avoid
doing, but seem intent on now.


Michael Lee Finney
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
In article <417kfc$1q3@engnews2.Eng.Sun.COM> Steve Clamage writes:
>If true and false were introduced into the preprocessor, they would 
>have to be predefined to the preprocessor numbers 1 and 0. They would
>then be the only prefined literals in the preprocessor. Why would this
>be superior to just using 1 and 0 in your code, given that there are
>no types to begin with? That is, IMHO 'true' gives no advantage
>whatever over '1' in a preprocessor expression, since it cannot mean
>anything different from '1', and since it must iteract with expressions
>with integer (not boolean) values.

Also, if true and false were reduced to 1 and 0 by the preprocessor,
overloading on type bool would not be possible.  I thought that
overloading was a big reason that bool was added to the language in
the first place.

--steve

Steve Vinoski  vinoski@ch.hp.com        (508)436-5904
Distributed Object Computing Program    fax: (508)436-5122
Hewlett-Packard, Chelmsford, MA 01824

Standard Disclaimer:
All opinions expressed are my own and do not represent
official statements of the Hewlett-Packard Company.

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Distribution:
Excerpts from netnews.comp.std.c++: 22-Aug-95 Re: true/false literal std
.. vinoski@apollo.hp.com (1339)

> Also, if true and false were reduced to 1 and 0 by the preprocessor,
> overloading on type bool would not be possible.  I thought that
> overloading was a big reason that bool was added to the language in
> the first place.

I would expect that if the preprocessor were enhanced to recognize
true/false it would only do so in the context of #if, or #elif.  I think
the potential for confusion arising from the use of 1/0 for true/false
in the preprocessor and true/false in C++ code warrants fixing the
preprocessor to maintain consistency. It seems it would be fairly
trivial to add two new literals named true and false to the
preprocessor's expression parser...

-Rob

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9508310634.1386@mulga.cs.mu.OZ.AU>
           fjh@munta.cs.mu.OZ.AU "Fergus Henderson" writes:

> "Brian T. Hill" <bhil@strata3d.com> writes:
> 
> >Who wants to use "true" or "false" in the preprocessor anyway? 
> 
> I do.
> 
> >What are you going to do:  #if true ... ?
> 
> Yes!  Amoung other uses, I'd use `#if true' rather than `#if 1'.
> I don't use `#if 1' very often, but I do use it occaisionally...
> The code ususally looks something like this:
> 
>         #if 1
>                 // alert! this is a temporary hack!!
>                 hack(); hack(); hack();
>         #else
>                 // this code disabled because ...
>                 ...
>         #endif

What's so wrong with saying what you mean:

    #ifndef USE_ORIGINAL_UNHACKED_CODE
        hack(); hack(); hack();
    #else
        // This code disabled because
        ...
    #endif

The point is why change the language to support your idiosyncacies?

-- 
Alan Griffiths               | Also editor of: The ISDF Newsletter
Senior Systems Consultant,   | (An Association of C and C++ Users publication)
CCN Group Limited.           | (ISDF editor  : isdf@octopull.demon.co.uk)
(agriffiths@ma.ccngroup.com) | (For ACCU see : http://bach.cis.temple.edu/accu)
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <809869855snz@ma.ccngroup.com>,
Alan Griffiths  <aGriffiths@ma.ccngroup.com> wrote:
>In article <9508310634.1386@mulga.cs.mu.OZ.AU>
>           fjh@munta.cs.mu.OZ.AU "Fergus Henderson" writes:
>
>> "Brian T. Hill" <bhil@strata3d.com> writes:
>>
>> >Who wants to use "true" or "false" in the preprocessor anyway?
>>
>> I do.
>>
>>
>>         #if 1
>>                 // alert! this is a temporary hack!!
>>                 hack(); hack(); hack();
>>         #else
>>                 // this code disabled because ...
>>                 ...
>>         #endif
>
>What's so wrong with saying what you mean:
>
>    #ifndef USE_ORIGINAL_UNHACKED_CODE
>        hack(); hack(); hack();
>    #else
>        // This code disabled because
>        ...
>    #endif
>
>The point is why change the language to support your idiosyncacies?


Another important advantage of using the descriptive preprocessor macro
names is that it is a much easier and more flexible when there is a need
to selectively turn on/off certain hacks.

It is very rare that all the hacks and conditionals get turned
on or off at the same time. Selectively controlling which hacks or
conditional code gets compiled in is much easier when descriptive
#if guards are used rather than #if 1 or #if true. And once you decide
to use descriptive names, there is very little difference between:

#define USE_ORIGINAL_UNHACKED_CODE 1
#define WORK_AROUND_CTOR_BUG       0

and

#define USE_ORIGINAL_UNHACKED_CODE true
#define WORK_AROUND_CTOR_BUG       false


-- 
Ajay Kamdar                               Email: ajay@lehman.com   
Lehman Brothers                           Phone: (201) 524-5048 

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Alan Griffiths <aGriffiths@ma.ccngroup.com> writes:

>What's so wrong with saying what you mean:
>[...alternative code not using `#if true'...]

There's nothing wrong with that.  I'm not suggesting that making the
preprocessor recognize `true' would add any significant additional
functionality to the language - clearly using `1' suffices.  Rather,
I'm suggesting that it would make the language easier to learn and
easier to use, and perhaps make some programs very slightly easier to
read and understand.  Sure, you can write it using `1', but shouldn't
the version using `true' work too?

>The point is why change the language to support your idiosyncacies?

I hope that the language will be changed, not to support my
idiosyncracies, but simply *because it makes sense*.  The change would
be trivial to implement, and if we don't make this change, then we
leave C++ with yet another nasty little trap for the unwary.

-- 
Fergus Henderson             |  #define x t=a[i],a[i]=a[m],a[m]=t
                             |  char a[]=" 12345678";main(m,i,j,t){for(i=m;i<
fjh@cs.mu.oz.au              |  9;x,i++)for(x,j=m;--j?(t=a[m-j]-a[m])-j&&t+j:
http://www.cs.mu.oz.au/~fjh  |  main(m+1)*0;);m-9||puts(a+1);} /* 8 queens */
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

The arguments for and against making the preprocessor recognize true and
false seem to be:

For:
  1) Why not?
  2) Uniformity
Against:
  1) Why bother?

I have personally encountered a case where it would have been nice for the
preprocessor to recognize true and false:  Rogue Wave Tools.h++ uses 
a typedef RWBoolean and macros TRUE and FALSE for dealing with boolean
values.  I tried converting it over to using the bool type one day, by
replacing 'int' with 'bool' in the typedef and '1' and '0' with 'true' and
'false'.  This worked fine for actual code that used the TRUE and FALSE
macros, but where they appeared in preprocessor directives I had to replace
them with something else.  Why should this be necessary?

Jason

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <9508311315.ZM8754@jabba>, Ajay Kamdar <ajay@lehman.com> wrote:
>In article <809869855snz@ma.ccngroup.com>,
>Alan Griffiths  <aGriffiths@ma.ccngroup.com> wrote:
>>In article <9508310634.1386@mulga.cs.mu.OZ.AU>
>>           fjh@munta.cs.mu.OZ.AU "Fergus Henderson" writes:
>>
>>> "Brian T. Hill" <bhil@strata3d.com> writes:
>>>
>>> >Who wants to use "true" or "false" in the preprocessor anyway?
>>>
>>> I do.
>>>
>>>
>>>         #if 1
>>>                 // alert! this is a temporary hack!!
>>>                 hack(); hack(); hack();
>>>         #else
>>>                 // this code disabled because ...
>>>                 ...
>>>         #endif
>>
>>What's so wrong with saying what you mean:
>>
>>    #ifndef USE_ORIGINAL_UNHACKED_CODE
>>        hack(); hack(); hack();
>>    #else
>>        // This code disabled because
>>        ...
>>    #endif
>>
>>The point is why change the language to support your idiosyncacies?
>
>
>Another important advantage of using the descriptive preprocessor macro
>names is that it is a much easier and more flexible when there is a need
>to selectively turn on/off certain hacks.
>
>It is very rare that all the hacks and conditionals get turned
>on or off at the same time. Selectively controlling which hacks or
>conditional code gets compiled in is much easier when descriptive
>#if guards are used rather than #if 1 or #if true. And once you decide
>to use descriptive names, there is very little difference between:
>
>#define USE_ORIGINAL_UNHACKED_CODE 1
>#define WORK_AROUND_CTOR_BUG       0
>
>and
>
>#define USE_ORIGINAL_UNHACKED_CODE true
>#define WORK_AROUND_CTOR_BUG       false
>
>

	This is true so long as you only ever intend to use these
flags as switches to the preprocessor.   From time to time, cases 
arise when you want to define a flag that will be used both as a 
preprocessor switch and as a constant in ordinary code.  For example,
something like 

#define BIG_ENDIAN true

	If you define it as 

#define BIG_ENDIAN 1

	functions overloaded on both bool and int don't work properly
when they are applied to BIG_ENDIAN, but if you don't the preprocessor
mishandles #if BIG_ENDIAN.   

	The necessary fix to the preprocessor is relatively simple.
In the description of #if, there is a sentence: ``After all
replacements due to macro expansion and the |defined| unary operator
have been performed, all remaining identifiers are replaced with the
pp-number |0|.'' Rewording this as ``After all replacements due to
macro expansion and the defined unary operator have been performed,
all remaining instances of the identifier true are replaced with the
pp-number |1|, and all other remaining identifiers are replaced with
the pp-number |0|.''  fixes the problem.  This sort of klugey special
case seems entirely in keeping with the current design of the bool
type (e.g. the bizarre rules about ++ and --).

   	Otherwise, we're going to end up seeing an awful lot of
definitions of the form

	#define true (1||true) 

(or one of it's many moral equivalents) in people's header files, just
to be sure they don't get bitten by this problem.









--
William E. Aitken 			    | Formal verification is the 
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: 	#if 1
: 		// alert! this is a temporary hack!!
: 		hack(); hack(); hack();
: 	#else
: 		// this code disabled because ...
: 		...

I prefer:
	#ifdef PUT_BUG_DESCRIPTION_HERE
 		// this code disabled because ...
 		...
 	#else
 		// alert! this is a temporary hack!!
 		hack(); hack(); hack();
	#endif

This way, I can toggle which code to use without editing the file.

--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3224 days!
aishdas@haven.ios.com                     (16-Oct-86 -  1-Sep-95)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Worship, Kindness</a>
<a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In <425umg$n9b@news1.halcyon.com>, aitken@coho.halcyon.com (William E. Aitken) writes:
>	#define true (1||true) 

This approach had not occured to me (assuming that it works <g>).
Your idea for a definition of true (and its dual for false) is excellent
if the committe doesn't get the point.  This is the most useful idea
to come of the entire discussion -- barring the chance that the
discussion will get the idea across to the committe and they will
actually change the draft standard (perhaps with a wording such
as you suggested).

When I wrote the original post starting this thread I was hoping to
simply be told that the draft standard treated this correctly.
However, it started a looong thread where about half the people
want it treated properly and about half are appalled at the very
idea (don't ask me why, I guess they like programming in binary <g?).

Michael Lee Finney



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]