Variable declaration optimisation question

Ever since reading (in an unrelated manual, a long time ago), that I shouldn't assume variables I declare are initialised to any specific value I've always assigned them one in their declaration when it's critical to the program logic, even if it's also their default:

integer index = 0;
string text = "";
list data = [];

Am I adding to the processing burden of anything other than the complier by continuing to do so in LSL scipts?

Unless you're doing this in tight loops or getting real close to the script space limits, I wouldn't worry about it too much..


Yes but it's a pretty tiny amount of processing. This is one of those cases where I'd take readability over hyper-optimization unless it was in a function that really needed to be high performance.

I was wondering about this today but I'm not inworld to experiment. Say I declare an integer without assigning a value:

integer myNumber;

And then I add something to it:

myNumber += 1;

Will it error?

no, because i think it defaults to 0 if you don't assign a value, so

myNumber += 1; would be 1

That's true for local variables in C. It's not true for LSL. All LSL variables are initialized to a default value. The compiler generates the same code (including creating an empty list object if necessary) either way. Literally the same code: "integer x" is effectively just a shortcut for "integer x = 0;" and so on.

As a bit of a displacement activity I did this:

integer my_integer;
float my_float;
vector my_vector;
list my_list;
rotation my_rotation;
string my_string;
key my_key;

string Boolean2String (integer test)
{
    if (test) return "TRUE";
    else return "FALSE";
} 

default
{
    state_entry ()
    {
        llOwnerSay ("(string) my_integer: " + (string) my_integer);
        llOwnerSay ("(string) my_float: " + (string) my_float);
        llOwnerSay ("(string) my_vector: " + (string) my_vector);
        llOwnerSay ("llList2CSV (my_list): " + llList2CSV (my_list));
        llOwnerSay ("(string) llGetListLength (my_list): " + (string) llGetListLength (my_list));
        llOwnerSay ("(string) my_rotation: " + (string) my_rotation);
        llOwnerSay ("(string) my_string: " + (string) my_string);
        llOwnerSay ("(string) my_key: " + (string) my_key);
        llOwnerSay ("(my_integer == 0): " + Boolean2String (my_integer == 0));
        llOwnerSay ("(my_float == 0.0): " + Boolean2String (my_float == 0.0));
        llOwnerSay ("(my_vector == ZERO_VECTOR): " + Boolean2String (my_vector == ZERO_VECTOR));
        llOwnerSay ("(my_list == []): " + Boolean2String (my_list == []));
        llOwnerSay ("(my_rotation == ZERO_ROTATION): " + Boolean2String (my_rotation == ZERO_ROTATION));
        llOwnerSay ("(my_string == \"\"): " + Boolean2String (my_string == ""));
        llOwnerSay ("(my_key == NULL_KEY): " + Boolean2String (my_key == NULL_KEY));
        if (my_key) llOwnerSay ("(my_key): TRUE");
        else llOwnerSay ("(my_key): FALSE");
    }
}

Which produces this result in SL:

[16:20]  Object: (string) my_integer: 0
[16:20]  Object: (string) my_float: 0.000000
[16:20]  Object: (string) my_vector: <0.00000, 0.00000, 0.00000>
[16:20]  Object: llList2CSV (my_list): 
[16:20]  Object: (string) llGetListLength (my_list): 0
[16:20]  Object: (string) my_rotation: <0.00000, 0.00000, 0.00000, 1.00000>
[16:20]  Object: (string) my_string: 
[16:20]  Object: (string) my_key: 
[16:20]  Object: (my_integer == 0): TRUE
[16:20]  Object: (my_float == 0.0): TRUE
[16:20]  Object: (my_vector == ZERO_VECTOR): TRUE
[16:20]  Object: (my_list == []): TRUE
[16:20]  Object: (my_rotation == ZERO_ROTATION): TRUE
[16:20]  Object: (my_string == ""): TRUE
[16:20]  Object: (my_key == NULL_KEY): FALSE
[16:20]  Object: (my_key): FALSE

The only vaguely interesting thing I see there is that the default value for a key appears to be a non-null and invalid key.

Possibly another vaguely interesting thing to note is that when I tried it in LSLEditor 2.39, I got a different result for a rotation:

new: (my_rotation == ZERO_ROTATION): FALSE

Yep - the default value for keys is "".

See also: http://jira.secondlife.com/browse/VWR-7362

It still boggles me that LSL doesn't store keys internally as a 128 bit unsigned integer.

Thanks, that was worth it for the bit about using "" instead of NULL_KEY to pad unneeded key parameters.

Really? I bet it actually doesn't..

we interrupt this thread to remind any novice scripters who may stumble across it that global declaration default values apply only when the script is reset. If you wish the value to be initialized every time the script is rezzed or attached, you must do so explicitly within an on_rez or attach event.

*returning you to your scheduled programming*

Um, that's what I said.

Let me insert one key word here:
Important point: that applies only for GLOBAL declarations. I ran into a script where the poor fellow had copied all the LOCAL variable declarations to state_entry() and was changing them there and wondering why they weren't changing in the event they were actually used.

Fixed, ty!

You're really boggled that LL wouldn't do something obvious to help residents?

No, I'm boggled that LL wouldn't do something obvious to help LL. It's more hassle for the compiler, code generator, and runtime to deal with strings than scalars.

They can't fix it now, it'd break the hack of sending strings in the key parameter of link messages.

You are a less cynical ferrit than I, then.. I'm not even a little boggled.