The difference between extern and input - page 5

New comment
 
Alexey Navoykov:

Imagine that these initialisations are done in different include files. Then the final result will depend on the order in which these files are included.

Well - even such obvious bugs with these externs

So I'm writing that there's no sense in them, they are only for compatibility with old code - replace extern with input and correct errors... unclear purpose.... extern is meaningless - look it up

 
Alexey Navoykov:

Unfortunately, the implementation of extern variables in MQL5 is not finalized, and that's why I don't recommend using it - it might cause problems. I mean the lack of control over the mandatory one-time initialization of these variables.

For example, you may write it in such a way:

and there will be no error. Imagine that these initializations are performed in different plugins. Then the final result will depend on the order in which these files are included.

Or we can write it like this (executable file):

here we haven't initialized the extern-variable at all, but there's no error either.

Accordingly, there is no control over whether the same variables are defined in other files or not. You can accidentally change its name, but the program will compile as if nothing had happened, although in other files we have a variable with a different name.

All in all, it does not fit anywhere. That's why it's better to use functions instead of extern-variables. They are guaranteed to have only one definition, no more and no less.

With this approach, you shouldn't use a computer at all. Because if you close your eyes and poke at the keyboard, you will get nonsense.

The real problem in extern occurs when you try to make extern from input. I don't remember the details, it happened long ago. As the result, I refused extern at all, declared a simple variable in the include file and set its value in the EA inite through a function call.

 
Igor Makanu:

there you go - even such obvious bugs with these externs

That's why I'm writing that there's no sense in them, they are only for compatibility with old codes - replace extern with input and correct errors... otherwise the help says... unclear purpose.... extern makes no sense - no matter how hard you look.

There is a sense. In MT5 in the included files extern is not input at all.

 
Dmitry Fedoseev:

It makes sense. In MT5, extern in include files is not an input at all.

Why would you add externs to include files?

I don't know what is going on in the modern world of program writing, but I learned to write in procedural style, and then I started using OOP. The first and the second styles imply that each logical unit must be fully functional when transferred to another program, that is, a function is written - its description (header) contains all the parameters that it uses - it doesn't need iprouts - you cut and paste this function into another file, it "moved" as is - the same thing with classes.

And iprouts themselves should only create the user interface, they should always be described in the main file.


And using extern in the include file, imho way to get hard to trace the bug,@Alexey Navoykov above showed how it happens, unfortunately more than half of the variable names all programmers have to a letter the same name, the maximum difference in using capital/small letters, as an example MagicNumber or Magic - if you look KB, then every other variable, so in your method is a threat to "shade" extern in its variable, thankfully few people now use ecterps

 
Igor Makanu:

why add iprtu's in include files?

I do not know what is going on in the modern world of writing programs, but I learned to write in procedural style, then began to use OOP, both in the first and in the second style it is implied that each logical unit must be fully functional when transferred to another program, i.e. you wrote a function - in its description (in the title) have all the parameters it uses - it does not need iprouts - cut this function and inserted into another file, it "moved" as is - the same with classes.

And the iprouts themselves should only create the user interface, they should always be described in the main file.

Not so. In include files add externs. So that in include files you could use the inputs declared in the main file.

By the way, it's almost always needed just as soon as you start using include files.

 
Dmitry Fedoseev:

Not like this. Add externs to include files. So that in the include file you can use the inputs declared in the main file.

Incidentally, this is what you need almost as soon as you start using include files.

give an example of why extern should be used

 
Igor Makanu:

give an example of the appropriateness of using extern

It's been around for a while now.

 
Dmitry Fedoseev:

You shouldn't use a computer at all if you take this approach. Because if you close your eyes and poke at the keyboard, you get crap.

Of course we will get the rubbish, but it will hardly compile. The compiler's task is not to compile rubbish. And in this case it fails to do that.
 
Dmitry Fedoseev:

It's been here for a while now.

That's what I'm talking about.

Your example is the generation of hidden bugs, variable name x is often used.... wrote above

Imho it's supposed to look like this:

extern int x;

int z()
  {
   static int x;
   x=122;
   return x;
  }
 
Igor Makanu:

That's what I'm talking about.

Your example is the spawning of hidden bugs, the variable name x is often used.... wrote above

Imho it's supposed to look like this:

No way. Variable x should be available not just in one function, but in all functions. And even more - it should be available in the main file as well as in all connected files.

1234567
New comment