Declaring variables behind the loop or inside the loop?

New comment
  
   string st = "";
   for (int i = 0; i < 1000; i++)
   {
      st = i;
      ...
   }

or

   for (int i = 0; i < 1000; i++)
   {
      string st = i;
      ...
   }

Is there a difference? given all the optimisations of the mql5 compiler?

 
pivalexander:

or

Is there a difference? given all the optimisations of the mql5 compiler?

There is no difference in compilation, so feel free to use the second option.
 

Personally, I prefer the former.

Just in case. The compiler may be smart enough not to allocate memory every time, but in the first case I specify it explicitly, but in the second case it is an implicit result of the compiler, because according to language logic the variable must be created inside a block and it must be removed on exit from the block.

And equating int to string without transformation is bad practice.

 
pivalexander:

Is there a difference? given all the optimisations of the mql5 compiler?

Don't listen that there is no difference. Use only the first option, there is a difference. I haven't studied the disassm from mcl though.

 
Georgiy Merts:

Personally, I prefer the former.

Just in case. The compiler may be smart enough not to allocate memory every time, but in the first case I specify it explicitly, but in the second case it is an implicit result of the compiler, because the logic of the language is to create a variable inside a block, and when you exit the block, it must be deleted.

And equating int to string without converting it is bad practice.

George is right, it is not guaranteed.

And we get a warping of the implicit conversion from 'number' to 'string'.


And this is exactly how we get rid of indeterminacy and warping.

for (int i = 0; i < 1000; i++)
   {
      static string st = IntegerToString(i);
      ...
   }
 
Georgiy Merts:

Personally, I prefer the former.

Just in case. The compiler may be smart enough not to allocate memory every time, but in the first case I specify it explicitly, but in the second case it is an implicit result of the compiler's work

Are you kidding? It's such a trivial situation for the compiler that there's nothing to talk about. You may be so paranoid about it that you just need to code in assembler. Although even that already becomes senseless nowadays. You will have to try hard to beat optimization of modern compilers.

p.s. Maybe I was a bit excited about triviality in the case of string buffer. But it is guaranteed to be saved in MQL, not only inside the loop but even between function calls. This topic was discussed here more than once
 

Don't listen to them, they'll tell you a lot about it here ))

// c++
#include <iostream>
#include <string>
using namespace std;

void* operator new(size_t sz) {
    void *ptr = std::malloc(sz);
    if (ptr)
        return ptr;
    else
        throw std::bad_alloc{};
}


int main() {
        for (uint i = 0;  i < 3;  ++ i) {
                string s;
                char buf[10];
                sprintf(buf, "%u", i);
                s = "sfjhidfsrtea111";
                s += buf;
                cout << s << '\n';
        }
}

I compile gcc -O3, run it under debugger, set breakpoint on operator new, get three calls. The same with clang.

Note: if string is taken out of loop, I get one call.

 
Alexey Navoykov:

Are you kidding? It's such a trivial situation for a compiler that there's nothing to talk about. If you're so paranoid, you may write code code purely in assembler. But even that is becoming senseless nowadays. You will have to try hard to beat optimization of modern compilers.

p.s. Maybe I was a bit excited about triviality in the case of string buffer. But it is guaranteed to be saved in MQL, not only inside the loop but even between function calls. This topic was discussed here more than once

No, I'm not.

Certainly, a normal compiler in this case should bring a variable declaration inside a loop to the outside.

I just think you should always trust the compiler and trust yourself. It is a compiler standard that a local variable is created when it is declared and is removed when the block in which it was declared is exited. So you should focus on this principle in the first place and not wait for the compiler to improve your code for you.

It's not about efficiency (modern compilers really do give very high quality code) but about programmer's thinking scheme. When I look at the sources from Kodobase, I often wonder how many small and simple but potentially dangerous defects they contain. In this case it is not very critical yet, the maximum what can happen is that the program will work a bit slower. Real errors might be much trickier.

 
Vict:

Don't listen to them, they'll tell you a lot about it here ))

I compile gcc -O3, run it under debugger, set breakpoint on operator new, get three calls. The same with clang.

Hence, if string is taken out of loop, I get one call.

It couldn't have done otherwise because you yourself interfered with optimization by breakingpoints. The essence of optimization is that it should not change the algorithm's logic. That's why it cannot be detected explicitly. If there is a breakpoint there, of course the compiler has no right to cut this code out. Did you expect that the compiler can jump over the breakpoint? )

You can detect optimization only by compiling code or measuring its performance, so that's the first thing you should do. And calm down )

 
Waiting for the measurements)
 
Alexey Navoykov:

It couldn't do otherwise because you have interfered with optimization by breakingpoints yourself. The point of optimization is that it must not change the algorithm's logic. That's why it cannot be detected explicitly. If there is a breakpoint there, the compiler naturally has no right to cut this code out. Did you expect that the compiler might jump over the breakpoint? )

You can detect optimization only by compiling code or measuring its performance, so that's the first thing you should do. And calm down )

Man, that's just wild dumb, what's there to comment on, a complete misunderstanding of how the debugger works.

About the speed - memory manager is not so dumb, and not the fact that it will ask the OS, may overuse earlier allocated. In general, use it how you want, it's up to you. But you should not convince others of this, at least until you provide concrete evidence, where are they?

1234567891011
New comment
Reason: