Errors, bugs, questions - page 2044

 
Alexey Navoykov:

Bug with initialisation of static variables. It was not present in old builds.

Who doesn't mind sending this to service-desk. I have no desire to communicate with them there anymore.

It's not a bug, it's been discussed from here. Extract from

Forum on trading, automated trading systems and strategy testing

Peculiarities of mql4 language, tips and tricks

Alexey Viktorov, 2017.04.30 08:54

The initialization sequence: (for those who don't know about it)

First, global level variables then static ones arranged depending on priority of functions, OnInit(), OnTick() or OnCalculate()... I wasn't interested in further, and I was not interested in local ones in my time. So it turns out in this code that the function is called before the static variables are initialized, hence the error we are speaking about. The function is called before the variable is initialized

 
fxsaber:

It's not a bug, it's been discussed from here. Extract from

So if it was discussed between you and Alexey Viktorov, that gives you reason to believe it's not a bug? ) And this man himself states that his level of programming knowledge is much lower than yours. That is, he can be crossed off the list. You are the only one left). Discussed it with yourself, so it is not a bug.)

It is a bug. It cannot be so in principle that initialization of a variable will be ignored and the code will continue to be executed by skipping over it. This is nonsense. And the initialization order doesn't matter here. The variable is either initialized or the compiler generates an error here. There is no third way. Otherwise it's not a programming language, but something else.

 

Another bug in the new builds:

template<typename T>
int F1(const T& array[])
{
  return ArrayMaximum(array);
}


template<typename T>
int F2(const T& array[]) { return F1(array); }


void OnStart()
  {
    int arr[4]= { 1, 2, 3 };
    Print(F2(arr));  // Выдаёт -1 !!!
  }


Eh, it's so crude. I thought I'd upgrade to the new builds, because the old ones don't accept products in the Market. And here's a bug on a bug!

 
Alexey Navoykov:

So if this was discussed between you and Alexey Viktorov, that gives you reason to believe it's not a bug? ) And this person himself states that his level of programming knowledge is much lower than yours. That is, he can be crossed off the list. You are the only one left). Discussed it with yourself, so it is not a bug.)

It is a bug. It cannot be so in principle that initialization of a variable will be ignored and the code will continue to be executed by skipping over it. This is nonsense. And the initialization order doesn't matter here. The variable is either initialized or the compiler generates an error here. There is no third way. Otherwise it's not a programming language, but something else.

You can cross it out, I never spread my fingers "what kind of programmer am I"...

And your mother doesn't tell you to read the documentation? I've inserted a quote from the documentation especially for such people.

There is one forum for trading, automated trading systems and testing of trading strategies

Peculiarities of mql4, tips and tricks

Alexey Viktorov, 2017.04.29 12:50

Is it okay that the help says static variable... read for yourself

A static variable can be initialized with a constant or a constant expression corresponding to its type , unlike a simple local variable which can be initialized with any expression.


But not a function.

This is how it works

#property strict
#property indicator_chart_window

int TestBrokenStatic()
{
   static int stInt = 101;
   stInt++;
   return stInt;
}

int OnInit()
{
   static int result = 0;
   result = TestBrokenStatic();
   Print("TestStatic Expected result 102   - Actual result=", result);
   result = TestBrokenStatic();
   Print("TestStatic Expected result 103   - Actual result=", result);
   
   return INIT_SUCCEEDED;
}

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
{
   return rates_total;
}
2017.04.29 13:49:51.546 !Test USDCHF,M15: TestStatic Expected result 103   - Actual result=103
2017.04.29 13:49:48.457 !Test USDCHF,M15: TestStatic Expected result 102   - Actual result=102
2017.04.29 13:49:40.089 Custom indicator Test\!Test USDCHF,M15: loaded successfully

 
Alexey Navoykov:

Another bug in the new builds:

Eh, it's so crude around here. I thought I'd upgrade to the new builds, because the old ones don't accept products in the Market. And then there's a bug on a bug!

And I've got it right!

 
Alexey Viktorov:

You can cross it out, I never spread my fingers "what kind of programmer am I"...

And your mother doesn't tell you to read the documentation??? Especially for these people, I've inserted a quote from the documentation

I see, then I apologize, I didn't notice it right away. It's amazing, of course, how they managed to change it without anyone noticing. What I don't understand is why the compiler doesn't react to an invalid operation being executed. I.e. there is a bug in any case
 
fxsaber:

I've got it right!


Hmmm, what is your build? Mine is 1653.

 
Alexey Navoykov:

So if this was discussed between you and Alexey Viktorov, that gives you reason to believe it's not a bug? ) And this person himself states that his level of programming knowledge is much lower than yours. That is, he can be crossed off the list. You are the only one left). Discussed it with yourself, so it is not a bug.)

It is a bug. It cannot be so in principle that initialization of a variable will be ignored and the code will continue to be executed by skipping over it. This is nonsense. And the initialization order doesn't matter here. The variable is either initialized or the compiler generates an error here. There is no third way. Otherwise it's not a programming language but something else.

If I find a logical (consistent) explanation of the result, I don't see a bug. I don't think it's acceptable to prove a bug if the result doesn't coincide with C++. It's someone in C++ who thought and did so. But they might not have thought so and therefore didn't do it. That's why it's better not to refer to something out there, but rely on your own inner concept of what must be. And it is desirable that this "own" should really be one's own. And not the result of imperceptible imposition of stereotypes "the way it should be" as you gain programming experience.

I don't mind being wrong. I am slowly learning on my own rake.

 
Alexey Navoykov:

Hmm, what's your build? I have 1653.

1653x64.

 
fxsaber:

1653x64.

Strange how there's a discrepancy then...


Have someone else check with themselves.

Reason: