LSL Compiler Suggestions

/13/76/3514/1.html#post22289

I thought it would be a good idea to have a single unified thread to catch people's compiler-specific suggestions, so here's what we have so far:

1. /* */ - style comment blocks
2. Grouped declarations, i.e. "integer a, b, c, d, e"
3. include statement

Here's another one...

if(x<gMapYSize-1) // Generates error

Enclosing the 1 in parens fixes it. Did you guys put comparisons at the same priority as subtraction or something?

I've seen this too, adding spaces fixes it also. I think there's a problem with the precedence of the '-' character, that is "-1" with no spaces is always a number, negative 1, so in the above you've got (a < b c) with no operator between b and c so it's an error.

If this is confusing, it's because I need coffee.

no more confusing than you usual postes .

btw, i agree with your conclusions Mr. WG.

I thought it was because keys have - in them. So gMapYSize-1 could be a (invalid) key. But you could be right. Do you have to have " around keys?

yeah, keys are strings. which means you can llGiveMoney("Nada Epoch", amount). which is bad for the unwary cause it just makes your money disappear, going to the non-existent object named "Nada Epoch". Everyone can thank bob bunderfield for that little bit of info.

edit-maybe i should say keys follow the same format as strings, rather than they are strings. hmm might be fun to test.

Rather, a string will be implicitly cast to key when a key is expected. I'm away from SL right now, but my guess is that strings that don't look like keys become NULL_KEY when cast. Explains why money disappears into the void in Nada's example, anyway.

they are strings for all intents and purposes.

key id;
default
{
    state_entry()
    {
        id = "I am not a key!";
    }

    touch_start(integer total_number)
    {
        if(id != NULL_KEY)
            llSay(0, (key)id);
        else
            llSay(0, "NULL_KEY");
    }
}

if you touch the prim this script is on, it says I am not a key!. you will also notice that in the llSay i put a (key) instead of a (string), it also works if there is nothing there and the line reads:

llSay(0, id);

Yes, that's right. Your example shows that key will be implicitly cast to string, and vice versa, exactly as described in the documentation. ;) They are not, however, the same data type, as keys cannot hold arbitrary string data. I also imagine keys are stored as 16 bytes rather than as one byte per character like a string.

I guess the real test will be if you can store more characters than keys are normally in them. heh not that it really matters

Here's another one... Either have the complier do a first pass to figure out all the function prototypes or let us write the prototypes ourselves, like in C:

list blah(vector v);
list duh(string s);

As it is now we have to put our functions "in order," because a function can't "see" another function that is defined "after" it. So we get "ERROR : Function call mismatches type or number of arguments." (Which is not exactly accurate...)

if (integer i = 0...etc.) would be nice. In line declaration 'n all.

Case switch too but eh we can live without it.

Do you mean with for() Tcoz, or with if()s ... or just either?