Author Topic: Global variable value state  (Read 5116 times)

jporkkahtc

  • Senior Community Member
  • Posts: 2620
  • Hero Points: 210
  • Text
Global variable value state
« on: December 19, 2016, 12:25:52 AM »
Whats supposed to happen with the value of globals?
In my module, I have:

int joe1 = 9;        // Retains value on module reload
static int joe2 = 9; // Static variables are lost on module load
definit()
{
    say("defInit joe1 = " joe1);
    say("defInit joe2 = " joe2);
    joe1 = joe1 + 1;
    joe2 = joe2 + 1;
}

Expected: Now, everytime I load the module, "joe1" continues to increment, and "joe2" gets reset to 9 -- this is expected.

Unexpected: When I close Slickedit and start it again, joe1 and joe2 retain their values ... continually restarting Slick edit doesn't keep incrementing their values as I would expect.

Odd: If I use Macro: SetMacroVariable and change the value of Joe1, then restart Slick, Slick retains the incremented value of Joe2 as well as the set value of Joe1.


Seems like there is some optimization here ... what makes Slick decide to write global variable values to the STA?



Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 6937
  • Hero Points: 531
Re: Global variable value state
« Reply #1 on: December 19, 2016, 02:51:09 AM »
This can be a confusing (non-obvious) area of the macro language.

When SlickEdit starts, it restores all global and static variables to the values in the local state file (or the global state file if no local state file exists). This is NOT like a C++ program where variables get their initial state. SlickEdit doesn't always write the local state file. Some actions trigger the state file to be written by calling _config_modify_flags(). For example, when a def_XXX variable is changed, _config_modify_flags(CFGMODIFY_DEFVAR) is called. Variables that do not have the "def_" prefix are not supposed to force the state file to be written.

Originally the purpose of restoring variables and other things was for performance. Now machines are much faster, and there are ways we can re-engineer this so there isn't a performance need for a local state file. For backward compatibility, SlickEdit will always have an option for writing to a local state file. It may even always be the default setting. Backward compatibility is more important than removing this odd variable restore issue.