List elements and typecasting

This is probably too minor to worry about, but it's good to know how it works.

List elements can only be accessed through the llList2XXX functions, right. And the element types are heterogenous, and can be mixed and matched. So what happens if I call llList2XXX on an element whose type doesn't match the XXX function call? And let's say it would be a meaningful typecast, like this example (this is an integer to string conversion):

list foo = [1];

integer i = llIist2Integer(foo, 0); // This is of course legal

string s1 = llList2String(foo, 0);
string s2 = (string)llList2Integer(foo, 0);

Between s1 and s2, is there any reason at all to prefer one over the other? Correctness / speed / memory usage ... ?

Thanks,
Ziggy

Probably s1, because it's the more direct approach. However, this only applies to strings. If you were doing, say, vectors, I would recommend s2. It wouldn't have strange errors when parsing a string to a list, and extracting data.

Thanks.

And assuming I need to manipulate the elements as strings as well as integers, it saves space to store them in the list as integers, right? I hope it does

Probably, but it might take your program longer to process.

Well, it's one set of numbers. Sometimes I need to do string concatenates with them, and sometimes I need to do math with them. I decided to store them as numbers. I doubt it makes a huge difference either way, especially with just a handful of numbers.

Just a personal preference, but if I have mixed types in a list, I tend to just treat them as strings, and type cast them as required (this is on extracting a value from the list).

list _lstList = [0, 1.234, <33.33333, 44.44444, 55.55555>];
string sTemp = llList2String(_lstList, 0);
integer nInt = (integer)sTemp;

Main reason I do this is I'll often build vectors off 3 floats:
vVec = <nFloat1, nFloat2, nFloat3>;
Storing that in a list and extracting it with llList2Vector() seems to be highly unstable :p ..but pulling it out with llList2String, then converting to a vector seems to work fine. (my hunch is the parser that builds vars gets confused because floats have a precision of 6, but vector floats have a precision of 5.. and somewhere the code just gets confused (because I'm storing my homemade vector with floats at a precision of 6).

Anywho, I've found that just using llList2String() then type casting works fine, just adds to the process a little. I'd imagen it eats up a bit more mem as well (but have never tested), mostly due to creating a local string var. (I'm guessing lists are something like type "variable".. and thus eat up a ton of mem no matter what).

Bos

I'm just hoping that once a list element has decided it's an integer, it takes less space to store the value than if that element were a string

It really would depend on how many digits it is. A one digit string is probably smaller than an integer.

Hmm... good point. Hadn't thought about that