|
|
| Line 1: |
Line 1: |
| − | If you test for a variable's truth value by testing if it is equal to TRUE you may not get the correct result since TRUE == x is a true expression only when x is 1, yet all non-zero values are also not FALSE; FALSE != x is true when x is not zero. There is an ambiguity whenever x is not 1 even though all non-zero values are treated logically as true. When x is 2, for instance, both TRUE == x and FALSE == x are false statements, leading one to conclude that x is neither TRUE nor FALSE when its value is 2 (or any other value besides 0 and 1). But this code snippet
| + | <snip pasted AxeMurderer content- see [http://social.bioware.com/wiki/datoolset/index.php?title=Talk:Boolean_constants&oldid=7093 this revision] for it> |
| − | <pre>
| + | |
| − | int b_X_is_True = FALSE;
| + | |
| − | if( x ) b_X_is_True = TRUE;
| + | |
| − | </pre>
| + | |
| − | will set the variable b_X_is_True to TRUE whenever the value of x is not zero. Clearly when x is 2 the language treats x as a true value logically.
| + | |
| | | | |
| − | The problem is that the identifier TRUE must be given a value, and that value must represent all non-zero values to be accurate. But a single value cannot represent many different values so there is ambiguity everywhere except at the value the constant is actually assigned. FALSE on the other hand, also needs to be given a value, but it only has to represent one integer value...zero, because that is the only integer value treated logically as false. Any integer value tested against FALSE will be unambiguously resolved. Because of this ambiguity with the TRUE identifier, and the correspondingly unambiguous nature of the FALSE identifier, you may wish to instead test if your variable is not equal to FALSE rather than testing its equivalence to TRUE.
| + | Actually, though it is indeed perhaps a bit wordy and redundant at times, this information does seem quite pertinent to this page. It's the sort of thing that a scripter should be aware of when working with boolean constants in scripts, and since dascript doesn't have an explicit boolean type this seems like the best place for it to me. I'm going to reinstitute it and do some rewriting to make it less of a big block. [[User:BryanDerksen|BryanDerksen]] 15:47, 26 October 2009 (UTC) |
| − | | + | |
| − | Note also that it is never necessary, and furthermore wasteful, to explicitly "test for TRUE" or "test for NOT FALSE" in a boolean expression anyway. One would never write, for example:
| + | |
| − | <pre>
| + | |
| − | if( (x == y) == TRUE ) ... <-- redundant comparison with TRUE
| + | |
| − | if( (x == y) != FALSE ) ... <-- redundant comparison with FALSE
| + | |
| − | </pre>
| + | |
| − | because the sub-expression (x == y) will evaluate to TRUE or FALSE already. Additionally comparing the result to TRUE (or NOT FALSE) gives the exact same result for the entire expression as leaving the extraneous comparison out completely does. Thus the comparison with TRUE (or NOT FALSE) is redundant, unnecessary and a wasteful computation.
| + | |
| − | | + | |
| − | The same logic applies to expressions involving function calls. If a function returns a TRUE/FALSE value, it would be a redundant waste of CPU cycles to test if the returned value was TRUE.
| + | |
| − | <pre>
| + | |
| − | if( IsObjectValid( oObject) != FALSE) ... <-- this is redundant as well
| + | |
| − | if( IsObjectValid( oObject) == TRUE) ... <-- as is this, also it's ambiguous
| + | |
| − | if( IsObjectValid( oObject) ) ... <-- same thing, one less comparison
| + | |
| − | </pre>
| + | |
| − | In this case the return value of the function (TRUE/FALSE) has the same logic characteristics as the sub-expression (x == y) in the example above. So you can treat the function call as a boolean sub-expression just like (x == y) and therefore the same logic leads to the same conclusion concerning the overall expression.
| + | |
| − | | + | |
| − | In contrast, testing for FALSE or for NOT TRUE is perfectly acceptable:
| + | |
| − | <pre>
| + | |
| − | if( IsObjectValid( oObject) == FALSE) ... <-- this is not redundant
| + | |
| − | if( IsObjectValid( oObject) != TRUE) ... <-- not redundant either but is ambiguous
| + | |
| − | if( !IsObjectValid( oObject) ) ... <-- but this might be the best method
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | The identifier TRUE is only really useful for defining default values of boolean type parameters in a function definition, passing a true value to a function with a boolean parameter when you call it, or setting the value of a boolean type variable. There is no other place where you need it.
| + | |
| − | <pre>
| + | |
| − | void Dance( int bChaCha = TRUE)... <-- default value in function def
| + | |
| − | SetItemDroppable( oItem, TRUE); <-- boolean parameter in function call
| + | |
| − | int bStillLooking = TRUE; <-- set a variable value
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | Some will probably take the position that having the extra comparison in there makes the code more readable and obvious. It would be difficult to argue that point especially in some more complex expression situations. But it is functionally unnecessary and adding it does waste CPU cycles in exchange for that marginal increase in readability. Learning to read expressions without it having to be there would benefit anybody.
| + | |
Actually, though it is indeed perhaps a bit wordy and redundant at times, this information does seem quite pertinent to this page. It's the sort of thing that a scripter should be aware of when working with boolean constants in scripts, and since dascript doesn't have an explicit boolean type this seems like the best place for it to me. I'm going to reinstitute it and do some rewriting to make it less of a big block. BryanDerksen 15:47, 26 October 2009 (UTC)
