www.digitalmars.com         C & C++   DMDScript  

D - bool is not an integer?

reply Russ Lewis <russ deming-os.org> writes:
I would suggest that bool NOT be an integer type.  All conditional tests
should return bool and all conditional expressions should only accept
bools, not integers.

That would mean no casts (implicit or explicit) from one to the other.
The general idea is to prevent this classic bug:

int a,b;
if( a = b) ...

This returns an integer which is passed to the if.  Some compilers
notice this and issue warnings, but that solution is not necessarily
reliable and it increases compiler complexity.

Making bool's and int's different types also reduces the number of
operators we need.  The &&, ||, and ~ operators could all be deprecated:

bool & bool        logical  AND
bool | bool          logical OR
!bool                  logical NOT

int & int              bitwise AND
int | int                bitwise OR
!int                     bitwise NOT

I suggest the & and | operators because they are shorter to type, and
the ! operator over the ~ operator because it is better known.
Aug 17 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Your points are well taken. One of my problems with a separate bool type is
that a bool can have only two values, yet it is represented by a type that
can contain many values. It just never seems to feel right. -Walter

Russ Lewis wrote in message <3B7D5282.5AF7C365 deming-os.org>...

I would suggest that bool NOT be an integer type.  All conditional tests
should return bool and all conditional expressions should only accept
bools, not integers.

That would mean no casts (implicit or explicit) from one to the other.
The general idea is to prevent this classic bug:

int a,b;
if( a = b) ...

This returns an integer which is passed to the if.  Some compilers
notice this and issue warnings, but that solution is not necessarily
reliable and it increases compiler complexity.

Making bool's and int's different types also reduces the number of
operators we need.  The &&, ||, and ~ operators could all be deprecated:

bool & bool        logical  AND
bool | bool          logical OR
!bool                  logical NOT

int & int              bitwise AND
int | int                bitwise OR
!int                     bitwise NOT

I suggest the & and | operators because they are shorter to type, and
the ! operator over the ~ operator because it is better known.
Aug 17 2001
next sibling parent reply Ben Kuhn <benk improvsys.com> writes:
Walter wrote:


 Your points are well taken. One of my problems with a separate bool type is
 that a bool can have only two values, yet it is represented by a type that
 can contain many values. It just never seems to feel right. -Walter


Walter,

I would tend to agree with the original poster here.  If the programmer really
cares about the non-zero value of a boolean value, then they're really looking
for an integral value anyhow.  I don't know compiler theory all that well, but
I would think that if the compiler were aware of the intention of using a
boolean, that it could generate better assembly code as well.  I think there is
a valuable semantic difference between the types, and the distinction can save
much pain in using the language.  Add up the time that every programmer out
there spends at least once, and usually numerous times, in there life finding
the bug that the original poster mentioned, then multiply that by the potential
millions who could use / derive value from this spec.

What is the cost of having a seperate boolean value, aside from a few
characters in source files for the '== 0', and a relatively simple extra type
in compilers?  Is there some other tradeoff that I'm missing here?

--

Ben Kuhn
Aug 17 2001
next sibling parent Russ Lewis <russ deming-os.org> writes:
Ben Kuhn wrote:


 Walter wrote:


 Your points are well taken. One of my problems with a separate bool type is
 that a bool can have only two values, yet it is represented by a type that
 can contain many values. It just never seems to feel right. -Walter


 Walter,

 I would tend to agree with the original poster here.  If the programmer really
 cares about the non-zero value of a boolean value, then they're really looking
 for an integral value anyhow.  I don't know compiler theory all that well, but
 I would think that if the compiler were aware of the intention of using a
 boolean, that it could generate better assembly code as well.  I think there is
 a valuable semantic difference between the types, and the distinction can save
 much pain in using the language.  Add up the time that every programmer out
 there spends at least once, and usually numerous times, in there life finding
 the bug that the original poster mentioned, then multiply that by the potential
 millions who could use / derive value from this spec.

 What is the cost of having a seperate boolean value, aside from a few
 characters in source files for the '== 0', and a relatively simple extra type
 in compilers?  Is there some other tradeoff that I'm missing here?


What I've seen is a lot of people who use this:

rc = DoStuff()
if(rc)
  return rc;

Many of the people used to such tests would grumble to have to make it rc==0.
However, most of these tests, happily, are *far* better handled with
exceptions. :)
Aug 17 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
Ben Kuhn wrote in message <3B7D7887.A3EB66C8 improvsys.com>...

What is the cost of having a seperate boolean value, aside from a few
characters in source files for the '== 0', and a relatively simple extra


type

in compilers?  Is there some other tradeoff that I'm missing here?



Sometimes there can be a penalty in the generated code, because !=0 values
would have to be converted to boolean, as in:

    bool b = i ? 1 : 0;

There would also be confusion (I suspect) with the 'bit' type.
Aug 17 2001
parent reply "jacob navia" <jacob jacob.remcomp.fr> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9lk1k7$2b0f$1 digitaldaemon.com...

 Ben Kuhn wrote in message <3B7D7887.A3EB66C8 improvsys.com>...

What is the cost of having a seperate boolean value, aside from a few
characters in source files for the '== 0', and a relatively simple extra


 type

in compilers?  Is there some other tradeoff that I'm missing here?



 Sometimes there can be a penalty in the generated code, because !=0 values
 would have to be converted to boolean, as in:

     bool b = i ? 1 : 0;

 There would also be confusion (I suspect) with the 'bit' type.


I do generate that conversion in my compiler Walter. It is specified in the
ANSI C specs, and I think is a good thing. The code generated in x86
instructions (supposing the result already in a register)
    or    register
    setneq byte location

two instructions, not a big deal. Of course, sometimes there are other
sequences that get generated, but at most a few instructions. Not a big
deal, and you are sure that all booleans are either zero or one... This is a
conceptual simplification that is worth the few instructions. At 1GHZ now,
this doesn't matter much any more.
Aug 17 2001
parent "Walter" <walter digitalmars.com> writes:
jacob navia wrote in message <9lk5jl$2eb9$1 digitaldaemon.com>...

two instructions, not a big deal. Of course, sometimes there are other
sequences that get generated, but at most a few instructions. Not a big
deal, and you are sure that all booleans are either zero or one... This is


a

conceptual simplification that is worth the few instructions. At 1GHZ now,
this doesn't matter much any more.



I'll have to disagree that a few extra instructions are painless at 1GHz.
For example, when I turn my machine on the morning, I go off and get some
coffee, chat with friends, run errands, read the paper, and by the time I
get back it's almost at the logon prompt <g>.
Aug 17 2001
prev sibling parent "LuigiG" <ask.if iyou.need.it> writes:
"Ben Kuhn" <benk improvsys.com> wrote in message
news:3B7D7887.A3EB66C8 improvsys.com...

 Walter,

 I would tend to agree with the original poster here.  If the programmer


really

 cares about the non-zero value of a boolean value, then they're really


looking

 for an integral value anyhow.  I don't know compiler theory all that well,


but

 I would think that if the compiler were aware of the intention of using a
 boolean, that it could generate better assembly code as well.  I think


there is

 a valuable semantic difference between the types, and the distinction can


save

 much pain in using the language.  Add up the time that every programmer


out

 there spends at least once, and usually numerous times, in there life


finding

 the bug that the original poster mentioned, then multiply that by the


potential

 millions who could use / derive value from this spec.

 What is the cost of having a seperate boolean value, aside from a few
 characters in source files for the '== 0', and a relatively simple extra


type

 in compilers?  Is there some other tradeoff that I'm missing here?

 --


Hi,
I think it has advantages and disadvantages;
maybe it's not such a big deal if bool is treated as an integer, as long as
the compiler generates proper warnings, like in the above mentioned (a=b)
case..
But I too tend to prefer the bool type to be treated in the more restrictive
way;
the ideal for me is bool can only be true/false 1/0 and no other value, rel
ops should return always boolean and if/while should expect boolean
expressions.
I think that the 0=false and other-than-zero = true approach of some
compilers can be misleading for the programmers (some at least :);
Example: suppose the programmer incidentally uses bitwise & instead of
logical && in the following case

bool MyFunction()
{
    a is 0x55  nonzero, -> true
    b is 0xAA nonzero, -> true

return a && b; // returns true
but...
return a & b;   // returns false

}

perfectly ok for the compiler if integer/bool can be freely mixed, however
true and true = false  is not very intuitive.

Also, each approach has some influence on the generated code;
for example if the compiler cannot assume false always = 0 and true always =
1, there are some cases in which it is forced to use normalization tricks,
(like SBB etc. on the x86) which would (could) be unnecessary with a
restrictive bool type. (it can also happen the other way around tho'!)

--Luigi
Aug 17 2001
prev sibling next sibling parent Christophe de Dinechin <descubes earthlink.net> writes:
Walter wrote:


 Your points are well taken. One of my problems with a separate bool type is
 that a bool can have only two values, yet it is represented by a type that
 can contain many values. It just never seems to feel right. -Walter


May I politely remark that you are taking an x86-centric view of the world
here? :-) For instance, consider IA-64. The IA-64 has 64 1-bit predicate
registers. These are real bools. Well, even in the x86 world, it's not a big
deal to allocate one bit per bool in a shared byte, and to have some hint in
your register/stack allocator to ensure that bools tend to be packed together.

Christophe
Aug 18 2001
prev sibling next sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter wrote:

 Your points are well taken. One of my problems with a separate bool type is
 that a bool can have only two values, yet it is represented by a type that
 can contain many values. It just never seems to feel right. -Walter
 
 Russ Lewis wrote in message <3B7D5282.5AF7C365 deming-os.org>...
 


...
Well, you could define 0 as false, 255 as true, and the values in 
between as values of maybe.  That would use all the bits (maybe).

This would allow comparison to be defined, but what would be the results 
of a branch?  Take both branches on different processors?  Flip a random 
number generator?

Alternatively, a bool could be defined as a bit vector of length 8(?), 
with the standard operations addressing the 0th element.  Or maybe the 
high bit.  (Are those the same, or different?)

I'm not sure what value either of these would have.  The bit vector 
seems cheapest.  The only additional operation needed if rotate, and 
that's usually an assembler primitive.
Aug 20 2001
prev sibling next sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
	Well, I can't offer any technical reasons but I agree with your feeling
here.  I find the C style logical operator very powerful.  Frankly I
wish you would add perl style 'until' and 'unless' structures as well as
the ability to have a statement followed by a loop or conditional
statement since I find it to be very expressive.  I find these help make
intentions clearer in certain cases.  I had no good technical reason for
that either so I head off asking.  
	In any case, I'm glad to see labeled breaks and continues, a redo might
be nice to avoid a goto, and I hope you keep the logical ops I know and
love.  They allow me to say more meaningful things with less verbage.

Dan

Walter wrote:

 
 Your points are well taken. One of my problems with a separate bool type is
 that a bool can have only two values, yet it is represented by a type that
 can contain many values. It just never seems to feel right. -Walter
 
 Russ Lewis wrote in message <3B7D5282.5AF7C365 deming-os.org>...

I would suggest that bool NOT be an integer type.  All conditional tests
should return bool and all conditional expressions should only accept
bools, not integers.

That would mean no casts (implicit or explicit) from one to the other.
The general idea is to prevent this classic bug:

int a,b;
if( a = b) ...

This returns an integer which is passed to the if.  Some compilers
notice this and issue warnings, but that solution is not necessarily
reliable and it increases compiler complexity.

Making bool's and int's different types also reduces the number of
operators we need.  The &&, ||, and ~ operators could all be deprecated:

bool & bool        logical  AND
bool | bool          logical OR
!bool                  logical NOT

int & int              bitwise AND
int | int                bitwise OR
!int                     bitwise NOT

I suggest the & and | operators because they are shorter to type, and
the ! operator over the ~ operator because it is better known.
Aug 24 2001
parent "John Carney" <john.carney pacific.net.au> writes:
"Dan Hursh" <hursh infonet.isl.net> wrote in message
news:3B8730FA.2A998BC0 infonet.isl.net...

 Well, I can't offer any technical reasons but I agree with your feeling
 here.  I find the C style logical operator very powerful.  Frankly I
 wish you would add perl style 'until' and 'unless' structures as well as
 the ability to have a statement followed by a loop or conditional
 statement since I find it to be very expressive.  I find these help make
 intentions clearer in certain cases.  I had no good technical reason for
 that either so I head off asking.


I'm a big fan of 'unless' & 'until' myself. From a compiler implementation
point of view, it's very cheap syntactical sugar but, as you suggest,
'unless (...)' can frequently express intent much more clearly than 'if
(!...)'


 In any case, I'm glad to see labeled breaks and continues, a redo might
 be nice to avoid a goto, and I hope you keep the logical ops I know and
 love.  They allow me to say more meaningful things with less verbage.
Aug 28 2001
prev sibling parent reply Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
"Walter" <walter digitalmars.com> writes:


 Your points are well taken. One of my problems with a separate bool type is
 that a bool can have only two values, yet it is represented by a type that
 can contain many values. It just never seems to feel right.


On many machines, quite a lot of the basic integer types are
represented using full registers, with superfluous bits.  Why do you
have problems with that?

-- 
Florian Weimer 	                  Florian.Weimer RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Aug 25 2001
parent reply "Bradeeoh" <bradeeoh crosswinds.net> writes:
 On many machines, quite a lot of the basic integer types are
 represented using full registers, with superfluous bits.  Why do you
 have problems with that?

 --



Because the logistics of bool are different than the logistics of integer.
Integer has (usually) 2^32 individual values, each with their own unique
meaning.  The concept of bool means that the value of the variable is either
"false" or "true".  With an integer implementation, you change the concept
of the bool to "false" or "not false".

Represent a bool with individual bits either on or off, and you can have 8
bools take up 1 byte, instead of 8 bytes, easy to implement with D's built
in bit type and bit array type.

Just an issue of semantics.  Proper semantics can help you "feel right"   :)

-Brady
Aug 25 2001
parent Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
"Bradeeoh" <bradeeoh crosswinds.net> writes:


 Because the logistics of bool are different than the logistics of integer.


Are they?


 Integer has (usually) 2^32 individual values, each with their own
 unique meaning.  The concept of bool means that the value of the
 variable is either "false" or "true".  With an integer
 implementation, you change the concept of the bool to "false" or
 "not false".


Not necessarily.  Sometimes it is useful not to consider
representation issues at all and think in terms of more abstract
operations on values.


 Represent a bool with individual bits either on or off, and you can have 8
 bools take up 1 byte, instead of 8 bytes, easy to implement with D's built
 in bit type and bit array type.


Yes, of course, but I don't see the relevance of this for 'bool's.
This is a representation issue, and I think we were talking about the
semantics and the operations available for values of the 'bool' type.


 Just an issue of semantics.  Proper semantics can help you "feel
 right" :)


Of course, you could make 'bool' an integer type, but please make it
distinct from the other integer types (no default implicit conversion,
for example).

-- 
Florian Weimer 	                  Florian.Weimer RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Aug 27 2001
prev sibling next sibling parent reply "John Carney" <john.carney pacific.net.au> writes:
"Russ Lewis" <russ deming-os.org> wrote in message
news:3B7D5282.5AF7C365 deming-os.org...

 I would suggest that bool NOT be an integer type.  All conditional tests
 should return bool and all conditional expressions should only accept
 bools, not integers.



Hear! Hear!

Cheers,
John Carney.
Aug 17 2001
parent Russ Lewis <russ deming-os.org> writes:
John Carney wrote:


 "Russ Lewis" <russ deming-os.org> wrote in message
 news:3B7D5282.5AF7C365 deming-os.org...

 I would suggest that bool NOT be an integer type.  All conditional tests
 should return bool and all conditional expressions should only accept
 bools, not integers.


 Hear! Hear!

 Cheers,
 John Carney.


LOL!

Of all my ideas for changes to D, I thought that this one would be by far the
most controversial.  Shows what I know...
Aug 17 2001
prev sibling next sibling parent reply Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
Russ Lewis <russ deming-os.org> writes:


 I would suggest that bool NOT be an integer type.


Yes, this elimenates several common errors often encountered in C
source code.


 Making bool's and int's different types also reduces the number of
 operators we need.  The &&, ||, and ~ operators could all be deprecated:
 
 bool & bool        logical  AND
 bool | bool          logical OR
 !bool                  logical NOT


What about short-circuit evaluation?  Perhaps this should be provided
by a non-overloadable operator.

-- 
Florian Weimer 	                  Florian.Weimer RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Aug 25 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Florian Weimer wrote:


 Russ Lewis <russ deming-os.org> writes:


 I would suggest that bool NOT be an integer type.


 Yes, this elimenates several common errors often encountered in C
 source code.


 Making bool's and int's different types also reduces the number of
 operators we need.  The &&, ||, and ~ operators could all be deprecated:

 bool & bool        logical  AND
 bool | bool          logical OR
 !bool                  logical NOT


 What about short-circuit evaluation?  Perhaps this should be provided
 by a non-overloadable operator.


Short-circuit evaluation is still possible, provided that both sides of the
operator return bools.

Ofc, short-circuit error handling wouldn't work:

doStuff() || exit(1);

but that's done better with exceptions anyhow.
Aug 26 2001
parent reply Florian Weimer <Florian.Weimer RUS.Uni-Stuttgart.DE> writes:
Russ Lewis <russ deming-os.org> writes:


 bool & bool        logical  AND
 bool | bool          logical OR
 !bool                  logical NOT


 What about short-circuit evaluation?  Perhaps this should be provided
 by a non-overloadable operator.


 
 Short-circuit evaluation is still possible, provided that both sides of the
 operator return bools.


IMHO, the '&' and '&&' distinction in C isn't clear enough to separate
both forms.  You seem to suggest to remove any syntactic difference
between the two.  I fear this has a negative effect on readability and
maintainability.

-- 
Florian Weimer 	                  Florian.Weimer RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Aug 27 2001
parent Russ Lewis <russ deming-os.org> writes:
Florian Weimer wrote:


 Russ Lewis <russ deming-os.org> writes:


 bool & bool        logical  AND
 bool | bool          logical OR
 !bool                  logical NOT


 What about short-circuit evaluation?  Perhaps this should be provided
 by a non-overloadable operator.


 Short-circuit evaluation is still possible, provided that both sides of the
 operator return bools.


 IMHO, the '&' and '&&' distinction in C isn't clear enough to separate
 both forms.  You seem to suggest to remove any syntactic difference
 between the two.  I fear this has a negative effect on readability and
 maintainability.


Sorry, I don't understand what you're getting at.  Can you explain in more
detail?
Aug 27 2001
prev sibling parent reply Russ Lewis <russ deming-os.org> writes:
Time to argue with myself (a bit).

I just was at a code review and saw people testing bit flags against a state
variable:

if(foo | INTERESTING_FLAG)
   ....
else if(bar | BORING_FLAG)
   ....

If we take my advice, this code becomes:

if(foo | INTERESTING_FLAG == INTERESTING_FLAG)
  ....

I *really* don't like the extra typing.  Plus, it's much harder to read.
So, I pondered a bit, and I'm thinking that maybe we could use the 'in'
keyword.  It would be as readable (or more) than the C version:

if(INTERESTING_FLAG in foo)
    ....

In the integer/integer context, in is just syntax sugar:
     intA in intB
is expanded by the compiler to
     ((intA | intB) == intA)
which obviously returns bool.
Sep 04 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 if(foo | INTERESTING_FLAG == INTERESTING_FLAG)


That one will be -always- true :/

I guess you mean:


 if(foo & INTERESTING_FLAG == INTERESTING_FLAG)


But you can also write it this way:


 if(foo & INTERESTING_FLAG != 0)


resulting in the same, and is the same logic as the implizid C statement: 
everything but zero is true, zero is false. 

- Axel
Sep 04 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Axel Kittenberger wrote:


 if(foo | INTERESTING_FLAG == INTERESTING_FLAG)


 That one will be -always- true :/


Grimace...you're right, the code is wrong (needs to be an AND)...but no, it
won't always be true...if foo has bits set that are not part of
INTERESTING_FLAG, then it would be false...


 I guess you mean:


 if(foo & INTERESTING_FLAG == INTERESTING_FLAG)




Righto.


 But you can also write it this way:


 if(foo & INTERESTING_FLAG != 0)


 resulting in the same, and is the same logic as the implizid C statement:
 everything but zero is true, zero is false.


Double grimace...don't know why I didn't think of that.  Wish I could say
that it was late at night when I posted, but it wasn't :(

Ok, so there is a faster way to do this than I said.  Yours *is* much
cleaner.
Sep 05 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Russ Lewis wrote:


 Axel Kittenberger wrote:


 if(foo | INTERESTING_FLAG == INTERESTING_FLAG)


 That one will be -always- true :/


 Grimace...you're right, the code is wrong (needs to be an AND)...but no, it
 won't always be true...if foo has bits set that are not part of
 INTERESTING_FLAG, then it would be false...


 I guess you mean:


 if(foo & INTERESTING_FLAG == INTERESTING_FLAG)




 Righto.


 But you can also write it this way:


 if(foo & INTERESTING_FLAG != 0)


 resulting in the same, and is the same logic as the implizid C statement:
 everything but zero is true, zero is false.


 Double grimace...don't know why I didn't think of that.  Wish I could say
 that it was late at night when I posted, but it wasn't :(

 Ok, so there is a faster way to do this than I said.  Yours *is* much
 cleaner.


Ack, got a problem here.  I just realized that unless we use some funky
(perhaps confusing) rules, unifying && and & breaks some precedence rules.
Look at this code:

if(foo & INTERESTING_FLAG != 0 &
   bar & BORING_FLAG != 0)
   ....

In old C syntax, & had high precedence, != had middle, and && had low.  Thus,
the C test worked

if(foo & INTERESTING_FLAG != 0 &&
   bar & BORING_FLAG != 0)

Theorhetically, it's not hard to tell the difference between the bool context
and the int context.  But if you use bison to parse it, you have a problem.

How onerous is it, do you think, to require the syntax to be:

if( (foo & INTERESTING_FLAG) &
    (bar & BORING_FLAG))

I think that that would be bug-prone, unfortunately.  I still like the theory
of unifying the operators...anybody have a good syntax for it?
Sep 05 2001
parent reply Axel Kittenberger <axel dtone.org> writes:
 Ack, got a problem here.  I just realized that unless we use some funky
 (perhaps confusing) rules, unifying && and & breaks some precedence rules.
 Look at this code:
 
 if(foo & INTERESTING_FLAG != 0 &
    bar & BORING_FLAG != 0)
    ....
 
 In old C syntax, & had high precedence, != had middle, and && had low. 
 Thus, the C test worked
 
 if(foo & INTERESTING_FLAG != 0 &&
    bar & BORING_FLAG != 0)
 
 Theorhetically, it's not hard to tell the difference between the bool
 context
 and the int context.  But if you use bison to parse it, you have a
 problem.
 
 How onerous is it, do you think, to require the syntax to be:
 
 if( (foo & INTERESTING_FLAG) &
     (bar & BORING_FLAG))
 
 I think that that would be bug-prone, unfortunately.  I still like the
 theory of unifying the operators...anybody have a good syntax for it?


Pascal had exactly this problem, AND and OR where both binary and boolean 
operators, and additionally to their sense of being binary they had higher 
binding than the equal operators. (remember then single = means equals in 
pascal)

IF a = 1 AND b = 2 THEN
BEGIN
        foo;
END


Any pascal user will scream and say it has to be written as:
IF (a = 1) AND (b = 2) THEN 

Or the compiler will implicitly see following:
IF (a = (1 AND b)) = 2 THEN

something very different :o)

I started learing programming with pascal, and later switched to C. And 
hence after all these years I'm still most times using these brackets even 
in C, altough it wouldn't need them, it's beeing a burned child. Just the 
same thing goes the other side, everytime i've now written a single equal 
sign meaning a compare my whole body cramps :o)

After actually trying the alternatives in practice one has to admit that a 
few C ideas weren't so bad after all :o) Okay c has still a lot of 
braindead quircks, but it's the only one that seems to satisfy industry :/

I for me have keeped the && and || parameters, in the sense of leaving the 
predecnce of all operator exactly as C. After having programmed both Pascal 
and C, having different precedence rules, I'm even after years not even 
having looked at pascal still unsure about their precedence, I don't want 
also to 'hurt' others like this :o)

Okay once you've coded a parser, you know them better :o) For C once you've 
looked at a parser for it, you realize what for braindead 
constructs the C grammar actually allows, no sane person could ever think 
of :o) Like anonymous structs in functions or

        void hallo (struct a {int i} b);

Okay but don't nail me if it's really correct C, just guessed it. 

Hmm how about:
        void (*)(void) (* a)(int);
Should be a function pointer to a function returning a function pointer.

I don't know about C++, but the gcc guys moan constantly about it, but I 
guess Walter could tell you more about C++ parsing :o)

- Axel
Sep 05 2001
parent reply "Walter" <walter digitalmars.com> writes:
Axel Kittenberger wrote in message <9n5vfr$2067$1 digitaldaemon.com>...

I for me have keeped the && and || parameters, in the sense of leaving the
predecnce of all operator exactly as C. After having programmed both Pascal
and C, having different precedence rules, I'm even after years not even
having looked at pascal still unsure about their precedence, I don't want
also to 'hurt' others like this :o)


It's important to keep the same precedence rules as C. Nothing will screw
programmers up more than to subtly shift them.
Sep 28 2001
parent reply mario jonathan.torino.artis.it (Roberto Mariottini) writes:
In article <9p29du$233h$1 digitaldaemon.com>,
 "Walter" <walter digitalmars.com> writes:
|> 
|> Axel Kittenberger wrote in message <9n5vfr$2067$1 digitaldaemon.com>...
|> >I for me have keeped the && and || parameters, in the sense of leaving the
|> >predecnce of all operator exactly as C. After having programmed both Pascal
|> >and C, having different precedence rules, I'm even after years not even
|> >having looked at pascal still unsure about their precedence, I don't want
|> >also to 'hurt' others like this :o)
|> 
|> It's important to keep the same precedence rules as C. Nothing will screw
|> programmers up more than to subtly shift them.

I agree, but what about not permitting this:

 if ( a < b && c < d || b < e && istrue(f) || isfalse(g)) {
     // guess you don't know when you go by here
     exit(2);
 }

Precedence and associativity say it is the same as:

 if ( (a < b && c < d) || (b < e && istrue(f)) || isfalse(g)) {
     exit(2);
 }

gcc suggests to use explicit parenthesis aound && within ||, and
I think this should be mandatory for D.

Ciao
Oct 02 2001
parent reply "Ben Cohen" <bc skygate.co.uk> writes:
In article <9pbvn5$1bes$1 digitaldaemon.com>, "Roberto Mariottini"
<mario jonathan.torino.artis.it> wrote:


 In article <9p29du$233h$1 digitaldaemon.com>,
  "Walter" <walter digitalmars.com> writes:


 gcc suggests to use explicit parenthesis aound && within ||, and I think
 this should be mandatory for D.


I agree.  Some C style guides recommend doing this sort of thing.   Rather
than changing the precedence, we can just remove it.
Oct 02 2001
parent reply a <a b.c> writes:
Ben Cohen wrote:

 
 In article <9pbvn5$1bes$1 digitaldaemon.com>, "Roberto Mariottini"
 <mario jonathan.torino.artis.it> wrote:
 

 In article <9p29du$233h$1 digitaldaemon.com>,
  "Walter" <walter digitalmars.com> writes:


 gcc suggests to use explicit parenthesis aound && within ||, and I think
 this should be mandatory for D.


 
 I agree.  Some C style guides recommend doing this sort of thing.   Rather
 than changing the precedence, we can just remove it.


	Funny, I always thought that the precedence of boolean operators were
as well understood and standard as those of addition and
multiplication.  Should we require explicit parens around all infix and
unary operations?  
	I had AND taught to me as boolean multiplication and OR taught as
boolean addition.  XOR and implication was always a bit of gray area,
but AND and OR were well defined.  I'd hate to clutter the expressions
in the cases were it isn't really needed.

Dan
Oct 02 2001
next sibling parent "Ben Cohen" <bc skygate.co.uk> writes:
In article <3BBA7764.458FBFCF b.c>, "a" <a b.c> wrote:


 	Funny, I always thought that the precedence of boolean operators were
 as well understood and standard as those of addition and multiplication.
  Should we require explicit parens around all infix and unary
 operations?
 	I had AND taught to me as boolean multiplication and OR taught as
 boolean addition.  XOR and implication was always a bit of gray area,
 but AND and OR were well defined.  I'd hate to clutter the expressions
 in the cases were it isn't really needed.


Yes, most of the problems seem occur when mixing other things in, e.g., &,
&&, ^, <<, etc.
Oct 03 2001
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
a wrote:


 Ben Cohen wrote:


 In article <9pbvn5$1bes$1 digitaldaemon.com>, "Roberto
 Mariottini" <mario jonathan.torino.artis.it> wrote:



 In article <9p29du$233h$1 digitaldaemon.com>, "Walter"
 <walter digitalmars.com> writes:


 gcc suggests to use explicit parenthesis aound && within
  ||, and I think this should be mandatory for D.


 I agree.  Some C style guides recommend doing this sort of
  thing.   Rather than changing the precedence, we can
 just remove it.


 	Funny, I always thought that the precedence of boolean
 operators were as well understood and standard as those of
 addition and multiplication.  Should we require explicit
 parens around all infix and unary operations?   	I had AND
 taught to me as boolean multiplication and OR taught as boolean
  addition.  XOR and implication was always a bit of gray
 area, but AND and OR were well defined.  I'd hate to
 clutter the expressions in the cases were it isn't really
 needed.

 Dan


In the context of mathematical logic, I was taught that they had 
the same precedence, and that parenthesis was always required if 
both operations were preformed.
Oct 03 2001