This will depend on the compiler and your best bet is to test - compile and inspect the emitted machine code.
No level of optimisation can (correctly) remove those tests. They could only be removed if both arguments were compile-time constants, and neither of these are, or if the compiler can prove that they won't change value between the tests.
Since binded
is static, the compiler can't know that the calls to the GL functions won't alter it.
None.
Sad story, but C++ assumes that if you call a function, then this function might produce all kinds of side effects, including changing the value of binded.ID (which the function somehow knows to do)
Except
If you make sure that the functions you invoke have absolutely no legal way to know about your bindend.ID
, either directly (by referencing it) or indirectly (because somebody else take a pointer of it and passed it around). Here's a simple example (assuming that side_effect()
is in a different translation unit)
int side_effect();
int k=1;
int main()
{
side_effect();
if (k!=0) return 0;
side_effect();
if (k!=0) return 0;
side_effect();
if (k!=0) return 0;
}
side_effect()
can use and change k
legally by declaring it as an external. No call of side_effect
can be optimized away.
int side_effect();
static int k=1;
int main()
{
side_effect();
if (k!=0) return 0;
side_effect();
if (k!=0) return 0;
side_effect();
if (k!=0) return 0;
}
It is not possible for side_effect
to access k
in an allowed manner, because you can't access statics in another translation unit. Therefore the code can be optimized to side_effect(); return 0
because k will not change, as long as side_effect() does not poke around in the memory. Which would be undefined behavior of course.
int side_effect();
void snitch(int*);
static int k=1;
int main()
{
snitch(&k); // !!!
side_effect();
if (k!=0) return 0;
side_effect();
if (k!=0) return 0;
side_effect();
if (k!=0) return 0;
}
The compiler has no way to know, if snitch()
saves its argument in a place where side_effect()
can change it, therefore no call to side_effect()
can be eliminated.
You get the same situation, if you have k
as a local variable: If there is a possibility that some unknown routine can access k
in a legal way, then the compiler can not make optimizations based on the value of k.
PS: Making k
const does not help, because it is legal to cast a const away. const-ness can not be used as a optimization hint.