confusion about the behaviour of the variables

 

If I compile as an expert

then when I change the StringVal, the backup changes immediately

and the last Print is not called

Where is the problem?

extern string StringVal = "string";

       string backup = "";

int init() {
   Print("=========================");
   Print("StringVal=",StringVal,"    backup=",backup);
   if(StringVal != backup){
      backup = StringVal;
      Print("StringVal=",StringVal,"< > backup=",backup);
   }
}

int start() { }
 

here's the second option

it turns out that the variables point to the same memory location after the first assignment

 if(firsttime) { backup = StringVal; 

I'd like to know what build this is from


here's an example

extern string StringVal = "string";

       string backup    = "";
       bool   firsttime = true;
       
int init() {
   Print("=========================");
   Print("StringVal=",StringVal,"    backup=",backup);
 
   if(StringVal != backup){
      if(firsttime) { backup = StringVal; Print(" First Call ===> backup = StringVal"); }
      Print("StringVal=",StringVal,"< > backup=",backup);
   }
   firsttime = false;
}

int start() {  }
 
wlad:

If I compile as an expert

then when I change the StringVal, the backup changes immediately

and the last Print is not called

Where is the problem?


Well, you manually change the StringVal and the init works immediately, that's right ...
 

it is clear that init() works

The problem is that 2. the variable is being updated independently of other conditions

there is no update condition - but the update happens!

 
When you change StringVal, change firsttime to false at the same time
 

Yes, it's all clear

The problem is that 2. the variable is set regardless of other conditions

ALWAYS

SERIOUS PROBLEM

 

here is a similar example

the value of the first variable is passed to the second variable only once and the value of the second variable should not change at further execution of the program

but every time the first variable is changed, the value of the second variable changes, which should not be

extern string Value = "O";
       
string temp_="";
bool   firsttime=true;
       
int start() {
   string txt=StringConcatenate( "  Value: ",Value,"\n",
                                 "  temp_: ",temp_,"\n",
                                 "  firsttime: ",firsttime);    
   if(firsttime) { temp_=Value; firsttime=false; } // значение присваевается тольо ОДИН раз   

   Print(txt);
   Comment(txt);                              
}
 
wlad:

here is a similar example

the value of the first variable is passed to the second variable only once and the value of the second variable should not change at further execution of the program

but every time the first variable is changed, the value of the second variable changes, which should not be

Whenever the extern variable is changed, the EA is restarted, which leads to initialization of variables declared at global level. This is correct. If you want to avoid this, use Global Variables.
 
Sepulca:
When extern variable is changed, EA is restarted, which leads to the initialization of variables, declared at global level. This is correct. If you want to avoid this, use Global Variables.

wrong - no initialization at all

here is a proof from the help

Global variables are initialised only once, right after the program is loaded into the client terminal's memory.

And in general, it's not about initialization but about variable change

Please read the code carefully

 

And the problem occurs only with variables of type string

With other types no problem!

 
wlad:

here's the second option

it turns out that the variables point to the same memory location after the first assignment

I'd like to know what build this is from


Here's an example

you always have the StringVal != backup and firsttime will always be true because it (init) is started only once but every time you restart the EA and a new one is started when you change info window or when you change set on terminal start . So when you changeStringVal you start the init again.

Reason: