Errors, bugs, questions - page 1356

 
Vasiliy Sokolov:
Very cool and most importantly ideologically correct. Two hands in favour!
Then it would be ideologically correct
class A { public:
        bool operator !=( A* ) {}
        bool operator  <( A* ) {}
};
void f()
{
    A *a1, *a2;
    a1 != a2; //здесь простое сравнение указателей вместо вызова operator !=()
    a1 <  a2; //здесь вызывается operator <()
}
operator!=() would be called instead of comparing pointers to equality like it is now. And pointer comparison could be performed by a special function similar to ::GetPointer(...)

But this is not done for the simple reason that it would bring significant inconvenience and the advantage would only be ideological correctness

 
Haven't received an update in a while: MetaTrader5 build 1159 (connected to MetaQuotes-Demo). Command compiler loads build 1162
 
Vasiliy Sokolov:

Then string is also a set of specific numbers. And a picture is also a number and an electrical pulse on a chip...

In general, study electrical engineering, colleague.

Here is a comparison of pointers in C++ and descriptors in MQL/C# and some other languages.

The challenge - you want to chat live with a mate.

1. Pointers. We know the street, house number and flat. We go to the address, wake up the friend, get a bubble, he is excited and chatting )).

2. Descriptors. We do not know the exact address, no one is allowed to enter the house, for example, it is the FSB building. There is a checkpoint in the house, which refuses to say the address by the name of a friend (by descriptor), refuses to let in the house (in the address space). Security calls the mate and asks him to come out. He comes out, you cheerfully pull out the bubble, he hisses, -what are you!!!! put it away immediately!!! So much for walking...Walking home with an unopened bottle in your hand, you shrilly realise that descriptors provide security in exchange for signposting capabilities.

 
Vasiliy Sokolov:

In general, study electrical engineering, colleague.

No other arguments?
 
A100:
No other arguments?
What about you?
 
A100:
I have code snippets where pointers are explicitly converted to numbers (for interfacing with external write/read systems, and for error analysis and debugging), if this is forbidden then flexibility will be reduced and I will have to redo.
Interesting argument, it takes some time to think about it. Please create a request, we will discuss it in details.
 

By the way, how about introducing * and & operators in MQL to allow explicit access to an object in the first case, and taking an object pointer in the second (instead of cumbersome GetPointer). The asterisk is a must, and there is nothing in the language to replace it.Without it, it is impossible to control situations like the one described by A100 above, when instead of the objects themselves some pointer actions are performed. Personally, this is a constant problem, I have to be constantly on the alert or specify A.operator=(B), A.operator!=(B) everywhere, i.e. brevity is lost, and overloading operators actually becomes meaningless.

I raised this problem once before, but the topic got stalled. Let's finish this issue at last.

 

Question about extern variables.

I faced a situation when extern variable changes during program execution, but when timeframe is changed, it takes the value set in the properties window again. For example, if before the start I set TradeEnable to EnableAll and change the value to EnableBuy during the program execution, then when the chart changes to another timeframe the value will return to EnableAll. The value I define in the timer event and output through Comment, there can be no error.

enum ETradeEnable {EnableAll, EnableBuy, EnableSell, DisableAll};
extern ETradeEnable TradeEnable = EnableAll;

The TradeEnable variable is not affected by the charts flipping. Read the manual - Unlike input variables, values of extern variables can be changed programmatically while the program is running.

That's how OnDeinit and OnInit are set up.

Question: I don't understand something or change of TradeEnable is a runtime error?

int LastDeinitReason = 0;

void OnDeinit(const int reason)
{
    LastDeinitReason = reason;
    if(reason==REASON_CHARTCHANGE || reason==REASON_TEMPLATE || reason==REASON_PARAMETERS)
        return;
    EventKillTimer();
// далее код при завершении работы советника
}

int OnInit()
{
    if(LastDeinitReason==REASON_CHARTCHANGE || LastDeinitReason==REASON_TEMPLATE)
    {
        LastDeinitReason = 0;
        return(INIT_SUCCEEDED);
    }
    if(LastDeinitReason==REASON_PARAMETERS)
    {
        SetParams();
        return(INIT_SUCCEEDED);                              
    }
// далее код инициализации при запуске
}
 
Alexey Navoykov:

Let's finish this issue at last.

Two operators are sacrificed there (== and !=) in order to preserve all the others.

I see a way out in a pattern.

template<typename T1, typename T2>
bool IsEqualPointer( const T1 *t1, const T2 *t2 )
{
    return ( ulong(t1) == ulong(t2) );
}

If operator==(!=) is defined, it will be called. If it is not defined, the pointers will be compared to equality. And if operator==(!=) is defined and pointers must be compared to each other on equality, this can be done through the specified template.

The changes to the existing system are minimal and the main thing is that they won't affect those who simply compare pointers to equality without operator==(!=) overloading.

 
A100:

Two operators are sacrificed there (== and !=) in order to preserve all the others.

I see a way out in a pattern.

If operator==(!=) is defined, it will be called. If it is not defined, the pointers will be compared to equality. And if operator==(!=) is defined and it is necessary to compare the pointers on equality, this can be done through the specified template.

The changes in the existing system are minimal and the main thing is that they won't affect those who simply compare pointers without operator==(!=) overloading.

Of course, you can do comparing and assignment through separate functions but what's the point? The point is to convince the developers to create a normal solution.