I have a shader code snippet of a blend function in Photoshop. However, due to the way the if statement is written, I have a hard time understanding what it returns.
This is the if statement I have trouble understanding:
if(float2(0,0) < 0)
...;
What is returned in case the value returns == or >?
The if statement will return true or false. If true c will be set to a new value. If it returns false c is not changed. At the end of the method c is returned. Ultimately c will be between 0 and 1.
Related
I'm learning c++ and I've run into some behaviour that I can't explain. The two pieces of code below provide different results, while I would expect them to be equivalent:
success = true;
vector<instruction>::const_iterator i;
for (i = instructions.begin(); i != instructions.end(); ++i) {
bool up = update(*i);
success = success && up;
}
and
success = true;
vector<instruction>::const_iterator i;
for (i = instructions.begin(); i != instructions.end(); ++i) {
success = success && update(*i);
}
I have the impression that the second version always takes the initial value of the iterator. Could someone explain me the reason?
The two pieces of code are not equivalent.
The first one always calls update, while the second one will not. The reason is that && does something called short-circuit boolean evaluation. If success is false, the second half of the expression is not evaluated.
Note that you did not post what update is or what is returned. Therefore we can only assume what may be able to be returned from update, which is either going to be true or false.
If you wanted update to always be called, it should be placed first in the && expression.
The operator && will not evaluate the right hand side if the result is computable with just the left hand side value. We call this short-circuiting.
Once success is false, update(*i) will no longer be called.
Aside from your first block of code (which always calls update(*i)), one fix is to use the operator & instead which always evaluates both arguments. Another fix is to write
success = update(*i) && success;
But that's vulnerable to recalcitrant refactoring. Better still, use
success &= update(*i);
But be aware of this comment by #Angew:
Using &= in a boolean context is dangerous. What if update now (or after a future refactoring) returns an int with the semantics "non-zero for true" (cf. isdigit and friends)? Remember that bool(true & 2) is false.
In C++ I read a coding guideline as "check return value in If control statement"
Like,
if(TRUE == fun1())
{
//Statements
}
When "fun1" returns True, internally in "if" statement it will be compared with “true”.
Is it necessary to compare externally.?
Is this a good practice or is this style of coding decreases performance.?
Comparing to TRUE is never a good idea.
If fun1 returns a BOOL, than its value is in fact an int and can have any int value. TRUE is just 1, FALSE is 0. But there are a lot of other values for an int. Comparing to FALSE is always save!
In a lot of cases. Functions return "something" and that should mean "TRUE" (!=0) as long as it is different from 0!
As long as you have a bool return value you can compare to true and false and it will always work.
It depends on the style, but I never use an expression to compare to a TRUE value (meaning not 0, not false). I always write the condition without an operator in the if statement. And it has the meaning for me "If fun1 is something" or "If fun1 succeeded"
if (fun1())
{
//Statements
}
In our company this is the normal coding style. And if we want to check the reverse. "If fun1 fails"
if (!fun1())
{
}
With modern compilers and processors there is no real speed impact.
Depends on the return type of fun1 and the type of TRUE.
If TRUE is true and fun1 returns bool, it doesn't decrease performance, because it does exactly what the if does itself. So it's just no-op clutter.
With other types, it looks dangerous and could even be wrong. Imagine a legacy-style function which returns int and is documented to return 0 on failure and a non-zero value on success (quite a few C standard library functions are like that). Then, let's say TRUE is true or 1. In this case, the function returning 2 (a perfectly valid non-zero value) would actually fail the condition!
So unless the types and values are so perverted that TRUE is 0 (which is not the case with MFC), I'd say it's actually harmful to compare with it.
I have isEmpty() function in my stack. And it looks something like below.
bool Mystack<T>::isEmpty() const //function 1
{
if(top==-1)
return true;
else
return false;
}
I saw a couple of online code for isEmpty(), which I could not understand. Below is the snippet.
bool Mystack<T>::isEmpty() const //function 2
{
return top == -1;
}
Question 1: Are both the functions doing the exactly the same task?
Question 2: If yes, then can some one please explain how the syntax in function 2 performing its task without using any if statement.
top == -1 is an expression. Assuming no operator overloads are involved, its return type is bool. It will have the value true if top equals -1 and the value false if that's not the case.
return top == -1; means "return the value of the expression top == -1". As I've shown above, this value is either true or false. These coincide exactly with the values returned from the if()-based code, so the two codes are equivalent.
In my code, I tend to use parentheses around "syntactically unusual" return statements, and I consider == one of them. So I would write this in my code (and I would certainly prefer it to the if version):
return (top == -1);
Yes, both functions work exactly the same. They return whether top equals -1.
In the first code, this is written somewhat "explicitly" (from the reader's perspective). Its English equivalent would be (roughly):
Evaluate the expression top == -1.
If the result is true, then return true, else return false.
The second code does it more subtly, and its rough English equivalent would be:
Return the result of the expression top == -1.
Yes, they do exactly the same thing.
Think about the semantics of an if statement. The condition evaluates to a bool and is checked against true. top==-1 will either evaluate to true or false, if it evaluates to true then the first form is executed and true is returned, otherwise the second form is evaluated and false is returned. This is exactly the same as the second version, just more verbose.
Answer 1: Yes, same task.
Answer 2: I have no exact idea of c++, but logically
return top == -1;
can be broken into
check if the value of top is equal to 1 or not.
1.1 if equal, return 1 [or TRUE] (as a result of comparison success)
1.2 if not, return 0 [or FALSE] (as a result of comparison failure)
As reference, from C99 standard document, chapter 6.8.6.4, paragraph 3,
If a return statement with an expression is executed, the value of the expression is
returned to the caller as the value of the function call expression.
and for that of c++11, chapter 6.6.3, paragraph 2,
. . . A return statement with an expression of non-void type can be used only in functions returning a value; the value of the expression is returned to the caller of the function....
For a lot of WINAPI methods, the return value is either 0 (failure) or nonzero (success). For example:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682565(v=vs.85).aspx
Return value
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.
My question is, for such a method, is it correct to test the return value with TRUE (which is a BOOL value equal to 1)? Or is it more correct to test if the return value is !FALSE instead?
Another nonrelated question is, when the return value is non-zero, what exactly is it? Can it be any value or from a set of values?
The signature of the method you mentioned is:
BOOL WINAPI DeleteTimerQueue(_In_ HANDLE TimerQueue);
In the Windows headers the type BOOL is defined as an int. This is for historical reasons, since in the days before C99 there was no bool type that we are now familiar with, and WinAPI have kept using the BOOL definition for many of the methods introduced later on.
Further, the Windows headers look very similar to this, if we take the liberty to simplify a bit,
typedef int BOOL
#define FALSE 0 // < note that #define <number> introduces an integer constant
#define TRUE 1
Thus your question can be interpreted as whether testing for !<integer> is equivalent to testing against a boolean value. The answer is yes, with C++ testing !0 == true and !n == false for any integral n > 0.
Another nonrelated question is, when the return value is non-zero, what exactly is it? Can it be any value or from a set of values?
It will be different for different WinAPI methods. Generally it can be any value, but since the return type is conceptually a boolean, it is okay to test it as a boolean.
so to sum up I should check it as …
The idiomatic way to check is:
if(!DeleteTimerQueue(handle)) {
/* handle the error case */
/* call GetLastError() where applicable */
}
/* otherwise proceed, the call succeeded */
Here is my code snippet:
int a;
if(a=8)
cout<<"Its right";
else
cout<<"Not at all";
getch();
return(0);
I'm getting the output Its right while I've not give any input there its just a assignment to the a=8.
**Borland Compiler** gives the following 2 warnings and executes the code.
1: Possible incorrect assignment (a=8)
2: 'a' is assigned a value that is never used.
When you write:
if(a=8)
You're assigning 8 to the variable a, and returning a, so you're effectively writing:
a = 8;
if(a)
This is non-zero, and hence treated as "true".
I (and the compiler) suspect you intended to write (note == instead of =):
if(a==8)
This is why you get the warnings. (Note that, in this case, a is still uninitialized, so the behavior is undefined. You will still get a warning, and may still return true...)
a = 8 assign 8 to a and returns the value of the assignment, that is 8. 8 is different from 0 and thus is considered true. the test apsses, and the program outputs "Its right".
you may have written if ( a == 8 ) which correctly tests the value of a without changing its value.
if(a=8)
implies assign a value of 8 to a and then use it to evaluate for the if statement. Since 8 is nonzero it essentially translates to TRUE (any value that is non-zero is true).
The first warning is because it's a frequent typo to write = in a condition test where you meant ==. The philosophy behind the warning is that it's a lesser burden for a programmer to rewrite if(a=b) to, say if((a=b)!=0) in the few cases he wants that, than to spend frustrating hours debugging the results if he mistakenly got an assignment instead of a comparison.
The second warning is just what it says: It looks like a mistake to have a local variable that you assign a value to but never use.
Since they are just warnings, you're free to ignore them if you think you know what you're doing. The compiler may even provide a way for you to turn them off.
Everyone else's answer is correct :)
if (a = 8) // Sets a to be 8 (and returns true so the if statement passes)
if (a == 8) // Check to see if a is equal to 8
I just want to add that I always (force of habit!) write if statements this way :
if (8 == a) {
Now, if I miss out one of the =, the compiler doesn't give me a warning, it gives me an error :)
You need a == (double equals). Single = is an assignment; when treated as an expression as you have done here, it evaluates to the value assigned, in this case 8. 0 is treated as False and anything else is True, so (a=8) == 8 == True.