Difference between revisions of "State variables"

From Second Life Wiki
Jump to: navigation, search
 
m (lsl code tagging)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
While all variables that might be used within more than a single state must be global right now, poluting memory statically, there also some problematic situation to purely event driven state scripts, where there is switched between a number of states with only little number of calls to self defined functions.
+
While all variables that might be used within more than a single state must be global right now, polluting memory statically, there also some problematic situation to purely event driven state scripts, where there is switched between a number of states with only little number of calls to self defined functions.   In such case, where there are only very little number of self defined functions that might be called with arguments, data management is, within one and the same state, only solved through static global memory(heap) / variable allocation.   A possible solution might be to allow state variables that are declared after the opening brace from a state declaration and which is/are allocated on stack only when the state is active, but removed from memory when a state becomes inactive from switching to another state.   If a stack based solution is not conform to compiler design, another solution might be to have a memory layout of heap based state variables, where there is a fixed allocation of the static part of state variables in size of the largest possible set form state variables, that is reused when switching from one state to another.   Such a solution of state local variables might help to provide a significant lower memory footprint in event driven multi state scripts.
In such case, where there are only very little number of self defined functions that might be called with arguments, data managament is, within one and the same state, only solved through static global memory(heap) / variable allocation.
+
 
+
A possible solution might be to allow state variables that are declared after the openening brace from a state declaration and which is/are allocated on stack only when the state is active, but removed from memory when a state becomes inactive from switching to another state.
+
If a stack based solution is not conform to compiler design, another solution might be to have a memory layout of heap based state variables, where there is a fixed allocation of the static part of state variables in size of the largest possible set form state variables, that is reused when switching from one state to another.  
+
 
+
Such a solution of state local variables might help to provide a significant lower memory footprint in event driven multi state scripts.
+
  
  
 
Example:
 
Example:
 +
<lsl>
 +
// Both variables "x" and "y" refer to the same memory location
 +
// while only one can be referenced when the given state is active
 +
// Overloading of names in sense of C++ must not be implemented if
 +
// this would cause too much problems with the actual given
 +
// LSL compiler.
  
 
state default
 
state default
Line 17: Line 17:
 
     {
 
     {
 
         llOwnerSay( (string)x ); // produces output "0"
 
         llOwnerSay( (string)x ); // produces output "0"
 +
        llOwnerSay( (string)y ); // produces compiler ERROR !!!
 
         state ExampleState;
 
         state ExampleState;
 
     }
 
     }
Line 23: Line 24:
 
state ExampleState
 
state ExampleState
 
{
 
{
     integer x = 1;  // with scope of "ExampleState" state
+
     integer y = 1;  // with scope of "ExampleState" state
  
 
     state_entry()
 
     state_entry()
 
     {
 
     {
         llOwnerSay( (string)x ); // produces output "1"
+
         llOwnerSay( (string)x ); // produces compiler ERROR !!!
 +
        llOwnerSay( (string)y ); // produces output "1"
 
         state default;
 
         state default;
 
     }
 
     }
 
}
 
}
 +
</lsl>
 +
--[[User:Eraz Rhode|Eraz Rhode]] 07:09, 29 May 2007 (PDT)
 +
 +
----
 +
 +
State functions (methods) would be interesting too. This sort of complication would require some language design (the exact implementation would end up being controversial). -- [[User:Strife Onizuka|Strife Onizuka]] 09:46, 29 May 2007 (PDT)

Latest revision as of 07:57, 3 April 2008

While all variables that might be used within more than a single state must be global right now, polluting memory statically, there also some problematic situation to purely event driven state scripts, where there is switched between a number of states with only little number of calls to self defined functions. In such case, where there are only very little number of self defined functions that might be called with arguments, data management is, within one and the same state, only solved through static global memory(heap) / variable allocation. A possible solution might be to allow state variables that are declared after the opening brace from a state declaration and which is/are allocated on stack only when the state is active, but removed from memory when a state becomes inactive from switching to another state. If a stack based solution is not conform to compiler design, another solution might be to have a memory layout of heap based state variables, where there is a fixed allocation of the static part of state variables in size of the largest possible set form state variables, that is reused when switching from one state to another. Such a solution of state local variables might help to provide a significant lower memory footprint in event driven multi state scripts.


Example: <lsl> // Both variables "x" and "y" refer to the same memory location // while only one can be referenced when the given state is active // Overloading of names in sense of C++ must not be implemented if // this would cause too much problems with the actual given // LSL compiler.

state default {

   integer x = 0; // with scope of default state
   state_entry()
   {
       llOwnerSay( (string)x ); // produces output "0"
       llOwnerSay( (string)y ); // produces compiler ERROR !!!
       state ExampleState;
   }

}

state ExampleState {

   integer y = 1;  // with scope of "ExampleState" state
   state_entry()
   {
       llOwnerSay( (string)x ); // produces compiler ERROR !!!
       llOwnerSay( (string)y ); // produces output "1"
       state default;
   }

} </lsl> --Eraz Rhode 07:09, 29 May 2007 (PDT)


State functions (methods) would be interesting too. This sort of complication would require some language design (the exact implementation would end up being controversial). -- Strife Onizuka 09:46, 29 May 2007 (PDT)