Optimization of constants does not work in all cases

[rweber89]

if(MAIN_MENU == TRUE && cmd == "TEST_TRUE")
{
llOwnerSay("TEST TRUE");
}
else if(MAIN_MENU == FALSE && cmd == "TEST_FALSE")
{
llOwnerSay("TEST FALSE");
}

---

Consider this for a moment, where MAIN_MENU is a constant integer passed in at module inclusion. Now the problem is that instead of optimizing this away (as we have no preprocessor directives to work with) - it does this:

---

if ((1 && (cmd == "TEST_TRUE")))
{
llOwnerSay("TEST TRUE");
}
else if ((0 && (cmd == "TEST_FALSE")))
{
llOwnerSay("TEST FALSE");
}

---

The compiler could check if an If( ... ) will always return 0 and then optimize it away. The same goes for 1 &&. So there could be a particular rule for optimizing away anything execution inside of an "0 &&" and removing an "1 &&" as that is completely redundant.

[furroy]

i don't think it can do this because LSL does not short circuit when executing boolean expressions, so you would get different behavior between forge and LSL in cases where expressions have side-effects.

however, this is a quirk with strings and i often use this to my advantage. if i have a toggle setting i want to strip away code i'll make a variable integer DEBUG=TRUE; and if (Debug) but sometimes i want to be able to flip this back and forth inside the generated LSL script. in these cases i'll do string DebugLSL="1"; and if (DebugLSL=="1") and this code will still appear in the final LSL.