bool CMessage::DoesAnyGroupMatch(bool * bUserGroup, bool * bMessageTargets, int nNumGroups)
{
for (int i=0; i<nNumGroups; i++)
if (bUserGroup & bMessageTargets)
{
return true;
break;
}
return false;
}
Simple question - Both 'break' and 'return' in a function
Author
Quote:Original post by Battousai
*** Source Snippet Removed ***
Do I need to use that 'break' statement in the 'if' block?
I see some potential issues in your code.
1)You are using pointers without checking if they are valid so hopefully that won't blow up in your face. Or consider using a const std::vector<bool> & instead of bool *. Then you will not even need to pass nNumGroups.
2)You are using & with booleans, perhaps you meant &&?
And just a personal pet peeve: you really don't need to put things like C, b, and n before variable names/class types as the type can be determined easily with modern IDEs and by examining the context. Again this is personal preference.
Author
Quote:Original post by nobodynews
I see some potential issues in your code.
1)You are using pointers without checking if they are valid so hopefully that won't blow up in your face. Or consider using a const std::vector<bool> & instead of bool *. Then you will not even need to pass nNumGroups.
2)You are using & with booleans, perhaps you meant &&?
And just a personal pet peeve: you really don't need to put things like C, b, and n before variable names/class types as the type can be determined easily with modern IDEs and by examining the context. Again this is personal preference.
Thank you all for your replies.
I will learn vectors one day, I promise :) It is in my todo list.
About & mark, I thought & was used for binary boolean operations and && for logical comparisons. Do I know something wrong?
Yes, & is for bitwise and, and && is for logical (or Boolean) and. I think the question is, why would you use bitwise when comparing two booleans.
Bitwise is usually only used to test if certain bits of an integer (or other whole number types) are set, Logical-and simply tests if both sides of the operator are non-zero (i.e. both bools are set to true).
Unless you're doing strange bit flags using booleans for some reason, you most likely want &&.
Bitwise is usually only used to test if certain bits of an integer (or other whole number types) are set, Logical-and simply tests if both sides of the operator are non-zero (i.e. both bools are set to true).
Unless you're doing strange bit flags using booleans for some reason, you most likely want &&.
Quote:Original post by dashurc
Unless you're doing strange bit flags using booleans for some reason, you most likely want &&.
Using & saves one conditional jump in the generated assembly.
Quote:Original post by DevFredQuote:Original post by dashurc
Unless you're doing strange bit flags using booleans for some reason, you most likely want &&.
Using & saves one conditional jump in the generated assembly.
Whilst one conditional jump is probably not worth optimizing for most people, if I recall correctly, the functional difference, in a boolean context, is that & evaluates both arguments but && will short circuit (i.e. in false & f(), f will be called, but in false && f(), f() won't be called).
I may be wrong.
Quote:Original post by TheUnbelieverQuote:Original post by DevFredQuote:Original post by dashurc
Unless you're doing strange bit flags using booleans for some reason, you most likely want &&.
Using & saves one conditional jump in the generated assembly.
Whilst one conditional jump is probably not worth optimizing for most people, if I recall correctly, the functional difference, in a boolean context, is that & evaluates both arguments but && will short circuit (i.e. in false & f(), f will be called, but in false && f(), f() won't be called).
I may be wrong.
Yes that's correct.
Whether or not the extra jump makes any difference depends on the processor and the circumstances of the call - it's possible for the jump to be faster than not in some cases.
Quote:Original post by nobodynewsUnless you are exporting the method from a DLL, in which case you need to be absolutely certain the vector implementations match across the client app and your DLL - particularly with vector<bool> which specialises down to a bitvector on most (ifnotall?) Std C++ lib implementations.
1)You are using pointers without checking if they are valid so hopefully that won't blow up in your face. Or consider using a const std::vector<bool> & instead of bool *. Then you will not even need to pass nNumGroups.
Quote:Original post by nobodynewsAnd just a personal pet peeve: you really don't need to put things like C, b, and n before variable names/class types as the type can be determined easily with modern IDEs and by examining the context. Again this is personal preference.Totally agree.
additionally, chucking in a couple of asserts wouldn't hurt your style: e.g.
assert(bUserGroup != NULL);assert(bMessageTargets != NULL);assert(nNumGroups >= 0);one last thing:
Quote:Original post by DevFredUsing & saves one conditional jump in the generated assembly.this is entirely personal opinion, but I absolutely hate optimisations like this. For me, the value of code clarity outweighs code speed (within reason obviously, and obviously there are exceptions to the rule, but as far as I'm concerned, these should only ever arise in mission critical/real-time control systems code)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
