Errors, bugs, questions - page 1953

[fxsaber]

Alexey Navoykov:

In general, I regretfully admit that the MQL compiler is not as smart as I thought it was.) I would even say it's not smart at all. ) I tried to make some simple examples and it turned out that even if I create a dummy object, which is not used anywhere and doesn't do anything, the compiler doesn't care about it. It's not optimized at all. I'm judging by the speed alone. And for some reason it works slower in new builds than in old ones.

The developers are aware of this. But such optimisation by the compiler is far from the priority of the tasks to be solved.

There are such ambiguities of the compiler as well.

[Alexey Navoykov]

fxsaber:

The developers are aware of this. But such optimization by the compiler is far from being a priority of tasks to be solved.

Yes, but it's just amazing: they boasted so much here earlier that they'd raised the quality of the optimizer to unprecedented heights but actually it cannot handle even such simple things. Let alone the more complex ones.

[Alexey Navoykov]

fxsaber:

That's why I propose to add to OnTesterInit the ability to change the default pass table:

int PassesSet( const int Index, const MqlParam& Parameters[] );

I assume that the parameter sets themselves are not stored in the system, but are calculated by the unique number of the combination (now it coincides with the pass number). Therefore it is only possible to change the order of the combinations, but not their composition. So, in this case, it would be something like SwapPasses(long index1, long index2).

But I could be wrong.

[fxsaber]

Alexey Navoykov:

I assume that the parameter sets themselves are not stored in the system, but are calculated using unique combination number (now it coincides with the pass number). Therefore, you can only change the order of combinations, but not their composition. I.e. in this case it would be something like SwapPasses(long index1, long index2).

This may be the case. Now the order can still be somehow influenced by Swap input lines in the EA source.

[Stanislav Korotky]

fxsaber:

This may be the case. Now the order can be somehow influenced by Swap input lines in EA source code.

It kills the optimization algorithm - it's like optimizing in random direction.

[fxsaber]

Stanislav Korotky:

This kills the optimization algorithm - it's like optimizing in a random direction.

We are talking about a complete overshoot in the first place.

[[Deleted]]

I am slowly learning OOP and have come across one non-obvious thing.

There is a class A, the fields of which are objects of another class B.

In class A, a constant method is called which returns an object of class B.

After that, a method of class B is called, which deletes parameters of the returned object.

It looks like this (the example is simplified, written in the browser):

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B GetBMember() const { return( m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();

The result is that Reset() does not work, i.e. the m_member fields are not cleared.

Question: shouldn't the compiler report (error/warning) at build time that a non-constant method for a constant object is being called (or something like that)?

[Sergey Dzyublik]

Alexey Kozitsyn:

Question: shouldn't the compiler report (error/warning) at build time that a non-constant method is being called for a constant object (or something like that)?

Perhaps the reason is an implicit copy constructor call as a result ofReset being called for a temporary object.

[[Deleted]]

Sergey Dzyublik:

Perhaps the reason is an implicit copy constructor call as a result ofReset being called for a temporary object.

Thank you. You're probably right, and the const specifier doesn't affect the result (no reset occurs both with and without it).

[Andrey Barinov]

Alexey Kozitsyn:

I am slowly learning OOP and have come across one non-obvious thing.

There is a class A, the fields of which are objects of another class B.

In class A, a constant method is called which returns an object of class B.

After that, a method of class B is called, which deletes parameters of the returned object.

It looks like this (the example is simplified, written in the browser):

The result is that Reset() does not work, i.e. the m_member fields are not cleared.

Question: shouldn't the compiler report (error/warning) at build time that a non-constant method for a constant object is being called (or something like that)?

Return pointers.

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B * GetBMember() const { return( & m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();