Okay, this is a bit basic but I'm having a hard time Googling it so what the hey...
Does C++ accept logic tests like:
Or do I have to keep writing it out as:Code:if (a <= x <= y) {}
?Code:if (a <= x && x <= y) {}
Okay, this is a bit basic but I'm having a hard time Googling it so what the hey...
Does C++ accept logic tests like:
Or do I have to keep writing it out as:Code:if (a <= x <= y) {}
?Code:if (a <= x && x <= y) {}
Yes it 'accepts' it (it's valid syntax), but it doesn't do what you want.
If the latter is what you want, then that's the way to write it.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
It's similar to saying:
which is probably never what you intend to say.Code:if (int(a <= b) <= c)
So, yes, you have to separate the expressions with &&.
Last edited by rudyman; 07-20-2008 at 07:24 AM.
Oh, okay. So what does the <= operator do in that context?
Exactly what you would expect from that expression : compares if the result of (a <= b) [which is either 0 or 1] is greater or equal to c.
The problem is that you didn't want to compare if the boolean value of (a <= b) is greater or equal to c, you wanted to compare if c is greater or equal to b as well as a <= b.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
If you're doing this sort of thing often, you could make a function out of it.
Code:bool in_range(bool min, bool num, bool max) { return min <= num && num <= max; }
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
I don't.
is perfectly readable as far as I am concerned . . . but if you don't think so, then by all means use parentheses.Code:if (a <= x && x <= y) {}
It's a common enough idiom.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
Yes, that particular example is fine, but it you start getting into more complex expressions and start using different operators, you might run into problems, especially where precedence is concerned. So I choose to always be explicit with parentheses so I don't have to remember when it's safe not to use them...
I've seen some code that did something like this:
and from the context it looks like the person who wrote it intended it to mean:Code:if ( ptr = func() == NULL )
but because of precedence it actually meant:Code:if ( (ptr = func()) == NULL )
Code:if ( ptr = (func() == NULL) )
I know what you mean; I always use parentheses when combining || and &&, for example, even though I know which one comes first in the precedence table . . . .
That reminds me. Sorry for the change of topic here, but is there anything wrong in using the assignment operator inside if/while statements/loops?
Without double-parentheses, that is?Code:if(c = read()) while(c = something)
Turbo C (I know) gives me an error, and GCC a warning (I think), but that's probably just because the compilers thought I meant ==, right?Code:if((c = read())) while((c = something))
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
I don't think there is anything wrong with it, but I'm pretty sure VC++ gives you a "assignment in conditional" warning because it's so easy to accidentally type = when you really mean ==
For that I usually get rid of the warning by doing:
Code:if ( (ptr = func()) != NULL )
Yeah, that's what I thought. I usually just put double-parentheses.
Of course, I try not to do that very often.Code:if((c = something())
Anyway, now that we've successfully derailed the thread . . . if you created your own class, I think you could probably overload the <= operator in such a way that "a <= x <= y" works as expected.
[edit] All I have at the moment is Dinkumware, so this hasn't been tested, but here's sort of how you could do it. I think.
[/edit]Code:#include <iostream> class type { private: int x; public: type(int x) : x(x) {} int get() { return x; } }; type *operator <= (type *left, type &right) { return left->get() <= right.get() ? left : 0; } type *operator <= (type &left, type &right) { return left.get() <= right.get() ? &left : 0; } int main() { type one(1), two(2), three(3); if(one <= two <= three) { std::cout << "true" << std::endl; } }
Last edited by dwks; 07-24-2008 at 12:06 PM.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
You can indeed. See Syntactic Aspartame: Recreational Operator Overloading which was published in the Feb 2006 issue of C/C++ User's Journal (the last issue before it's demise).
--
Computer Programming: An Introduction for the Scientifically Inclined