Comparison Operator Comparing Two Values ('y' || 'x' == blah)

Quote:

---

Originally Posted by LuckY

Two notes regarding these comments: 1) 'x' is a non-zero value (not just typically).

---

There is actually no requirement for that: that's why I used the word typically. There is nothing preventing someone designing a character set in which 'x' is zero, and everything else is relative to that (e.g. 'y' would be 1, 'z' would be 2, and 'a' would be -23.

Quote:

---

Originally Posted by LuckY

2) it is not necessarily true that 'anything' would never be evaluated because the order of evaluation is implementation dependant.

---

Incorrect. If we were talking about bitwise operations (eg a | b) you would be correct. However, both the C and C++ standards require that || and && operators are evaluated left to right with short circuiting. If a is non-zero, a || b is true and b is required to NOT be evaluated.

Quote:

---

Originally Posted by LuckY

(Note that I'm not ragging on grumpy; I just want to avoid people being mislead by false assumptions.)

---

I never take offence at being corrected; I'm well aware I'm imperfect. Whether you were ragging on me or not, you are the one who is incorrect in this case.

<more comments snipped>

Quote:

---

Originally Posted by grumpy

There is actually no requirement for that: that's why I used the word typically. There is nothing preventing someone designing a character set in which 'x' is zero, and everything else is relative to that (e.g. 'y' would be 1, 'z' would be 2, and 'a' would be -23.

---

That is simply an inane statement. You know very well that there exists no C/C++ compiler that defines it's own unique character set (making it's data completely incompatible with all standards) that does not conform to some form of ASCII or Unicode, especially not with the literal character 'x' assigned the value zero. I understand that you're attempting to make an otherwise very illuminating point, but it is simply an absurd supposition. The issue to which I addressed my point was not whether 'x' is required to be a value other than zero or not, but the fact that 'x' is not zero. Your stating that it "typically" isn't zero implies that there exist cases where iSlak may compile a program and discover that 'x' is equivalent to zero.

Quote:

---

Incorrect. If we were talking about bitwise operations (eg a | b) you would be correct. However, both the C and C++ standards require that || and && operators are evaluated left to right with short circuiting. If a is non-zero, a || b is true and b is required to NOT be evaluated.

---

You're a little late. This point has been mentioned repeatedly. More importantly, laserlight has actually quoted the C++ standard, providing irrevokable evidence and supporting the claims that I was mistakenly spreading a highly inaccurate mistruth as fact. As I stated previously, an instructor informed me (apparently, misinformed me, rather) years ago that the order of conditional operand resolution was implementation dependent. I never had occasion to doubt that information before now and have always programmed accordingly (e.g., saying: if ((ptr != 0) && ptr->foo()) instead of: if (ptr != 0 && ptr->foo())).

Quote:

---

I never take offence at being corrected; I'm well aware I'm imperfect. Whether you were ragging on me or not, you are the one who is incorrect in this case.

---

Admittedly so. Thank you for so necessarily pointing it out, yet again. If anyone else would like to jump in and announce my passing of misinformation, please, let us continue on with this ever-so-compelling discussion.

Quote:

---

Originally Posted by LuckY

That is simply an inane statement. You know very well that there exists no C/C++ compiler that defines it's own unique character set (making it's data completely incompatible with all standards) that does not conform to some form of ASCII or Unicode, especially not with the literal character 'x' assigned the value zero. I understand that you're attempting to make an otherwise very illuminating point, but it is simply an absurd supposition.

---

You miss my point entirely. Character sets are covered by a totally different set of standards from C/C++. There are are several, if you wish to go and hunt through (say) the ISO site. They all have different characteristics because they are designed for different purposes: one of those is the particular values that are associated with the letters a-z (or A-Z). More significantly, there is nothing to stop a new character set being defined in the future to meet future requirements.

Quote:

---

Originally Posted by LuckY

The issue to which I addressed my point was not whether 'x' is required to be a value other than zero or not, but the fact that 'x' is not zero. Your stating that it "typically" isn't zero implies that there exist cases where iSlak may compile a program and discover that 'x' is equivalent to zero.

---

Saying "x is typically not zero" means that, in most applications x is non-zero, but it is impossible to exclude current or future instances where it might be.

Quote:

---

Originally Posted by LuckY

You're a little late.

---

That's only because I don't sit on my computer waiting for responses to my posts. I respond when I get around to it. You responded to content of my post, and I responded in turn --- when I got around to it. And, as it happened, when I started typing my response, there were no others there. I was distracted by a few phone calls in the middle.

Quote:

---

Originally Posted by LuckY

This point has been mentioned repeatedly.

---

One way to get the message home to you ....

Quote:

---

Originally Posted by LuckY

More importantly, laserlight has actually quoted the C++ standard, providing irrevokable evidence and supporting the claims that I was mistakenly spreading a highly inaccurate mistruth as fact.

---

Yep. I'm not the only one who picked up you'd made an error.

Quote:

---

Originally Posted by LuckY

Thank you for so necessarily pointing it out, yet again. If anyone else would like to jump in and announce my passing of misinformation, please, let us continue on with this ever-so-compelling discussion.

---

One of the characteristics of forums like this is that people respond to messages as they see them. People can also post in parallel, meaning there can be multiple posts telling you the same thing. Sometimes multiple responses can come through, while someone is drafting a post. As happened in this case.

I suggest it is better to develop the maturity to cope with such little foibles of forums like this, rather than getting all huffy about it. Who knows, you might actually learn something useful.

Quote:

---

Originally Posted by LuckY

if ((ptr != 0) && ptr->foo())

---

what the big deal about using brackets,
when i use the brackets in a statment like that
its not to try and set a order, but for looks
i like the way it makes things looks.

Code:

---

if ((ptr != 0) && (ptr->foo())) //would be the normal way for me to
// write a statment that had multipel conditions.

---

also there are a few times when not having
the brackets changed the outcome, but im sure
with all of your experience you guys
have come across thsi yourself, if not ill elaborate.

Quote:

---

Originally Posted by grumpy

Quote:

---

Originally Posted by Lucky

Two notes regarding these comments: 1) 'x' is a non-zero value (not just typically).

---

There is actually no requirement for that: that's why I used the word typically. There is nothing preventing someone designing a character set in which 'x' is zero, and everything else is relative to that (e.g. 'y' would be 1, 'z' would be 2, and 'a' would be -23.

---

I trawled the C89 draft to see if it ruled out a character set with x equalling 0. Here's what it says on the null character:

Quote:

---

Originally Posted by C89 Draft

2.2.1 Character sets: A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string literal.

2.2.1.2 Multibyte characters: A byte with all bits zero shall be interpreted as a null character independent of shift state.

4.1.5 Common definitions <stddef.h>: wchar_t is an integral type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales; the null character shall have the code value zero and each member of the basic character set defined in 2.2.1 shall have a code value equal to its value when used as the lone character in an integer character constant.

4.10.7.2 The mbtowc function: The value of the code corresponding to the null character is zero.

---

The last two items refer specifically to wchar_t character rather than char characters so we have't yet got a explicit guarantee that the null character is zero, just that it must be "all bits zero". However, the draft standard does say this:

Quote:

---

Originally Posted by C89 Draft

3.1.2.5 Types: The type char, the signed and unsigned integer types, and the enumerated types are collectively called integral types. The representations of integral types shall define values by use of a pure binary numeration system.13 American National Dictionary for Information Processing Systems.) The representations of floating types are unspecified.

Footnote 13: A positional representation for integers that uses the binary digits 0 and 1, in which the values represented by successive bits are additive, begin with 1, and are multiplied by successive integral powers of 2, except perhaps the bit with the highest position.

---

This would seem to suggest that an integral variable with all bits zero must have the value zero and thus rule out having x equalling 0, although I stand to be corrected. The draft C standard also requires that 'a' have a positive value:

Quote:

---

Originally Posted by C89 Draft

3.1.2.5 Types: An object declared as type char is large enough to store any member of the basic execution character set. If a member of the required source character set enumerated in 2.2.1 is stored in a char object, its value is guaranteed to be positive.

---

Of course, I'm assuming that C++ has similar requirements.

Quote:

---

I never had occasion to doubt that information before now and have always programmed accordingly (e.g., saying: if ((ptr != 0) && ptr->foo()) instead of: if (ptr != 0 && ptr->foo())).

---

I think this is a good thing. Although I'm frequently guilty of it myself I believe using the logical operators to control program flow is poor style.

ILoveVectors: While extra brackets change the mathematical order of evaluation, as far as I know, they do not change the order of side affects. For example:

Code:

---

if ((ptr != 0) & ptr->foo())

---

I believe the compiler is free to evaluate ptr->foo() first, despite the extra brackets.

Quote:

---

This would seem to suggest that an integral variable with all bits zero must have the value zero and thus rule out having x equalling 0, although I stand to be corrected.

---

Right Anonytmouse. As Dave_Sinkula and LuckY stated in earlier posts, there is no way 'x' can have the value 0. And this quote that you just posted from the C89 draft further confirms this:

Quote:

---

2.2.1 Character sets: A byte with all bits set to 0, called the null character, shall exist in the basic execution character set; it is used to terminate a character string literal.

---