Fehler, Irrtümer, Fragen - Seite 2707

Neuer Kommentar
 
Sergey Dzyublik:

Ich bitte die Entwickler(@Ilyas), sich um den gefundenen Fehler zu kümmern.
Fehler MT5 (Build 2377): Bei der Auswahl einer geeigneten überladenen Funktion für ein Argument vom Typ Zeiger wird die Funktion mit der Typumwandlung in einen Zeiger auf dieElternklasse statt auf die Basisklasse höher priorisiert.
Auch kein Kompilierzeitfehler, wenn ein Zeiger auf eine Basisklasse einem Zeiger auf eine übergeordnete Klasse zugewiesen wird.

Möglicherweise verwandter Fehler:https://www.mql5.com/ru/forum/1111/page2682#comment_15591437

class A{};
class B : public A{};
class C : public B{};


struct T{
   static void test(A*){
      printf("A*");
   }
   static void test(C*){
      printf("C*");
   }
};

struct TT{
   static void test(B*){
      printf("B*");
   }
};

void OnStart(){
   B b;
   T::test(&b);            // Runtime Error: Incorrect casting of pointers.  Expected result: printf("A*");
   
   A a;
   TT::test(&a);           // Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
   B* ptr = &a;            // Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
}

Vielen Dank für die Nachricht.

Korrigiert von

Runtime Error: Incorrect casting of pointers.  Expected result: printf("A*");


Bleibt so wie es ist - dieser Code kann sich aus der Spezialisierung von Vorlagen ergeben (in einem Teil, der nicht funktioniert, aber die Kompilierung beeinflusst).

Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
Runtime Error: Incorrect casting of pointers.  Expected result: Compilation Error
 
Roman:

Ja, in Ihrem Code wird bei Port 80 der Header zurückgegeben, bei 443 nicht.
Ich habe mir Ihren Code noch einmal angesehen und konnte die Funktion SocketTlsHandshake nicht finden.
Ihr Code führt keinen Handshake durch. Dies könnte der Grund sein.
In der Hilfe zu dieser Funktion steht zwar, dass sie nicht erforderlich ist, wenn Sie eine Verbindung über Port 443 herstellen.

Genau, das ist nicht mein Code, sondern aus dem Beispiel der Entwickler (Sockets von MQ haben einige unintuitive Funktionen, die manchmal auf dem Forum herausgefunden werden, so wandte ich mich an Standard-Beispiel). Ich versuchte SocketTlsHandshake - es gibt immer false in allen Bedingungen zurück und hat keine Auswirkungen auf die Lösung von Problemen. Da die Zertifikatsdaten zurückgegeben werden, wird der Handshake durchgeführt. Sogar der Header, der Länge nach zu urteilen, kommt, aber er kehrt einfach nicht zum MQL-Code zurück. Der Fehlercode ist zu allgemein gehalten und der Fehler selbst ist fragwürdig. Wir brauchen eine Insiderperspektive.
 
Stanislav Korotky:
Genau, das ist nicht mein Code, sondern aus dem Beispiel der Entwickler (Sockets von MQ haben einige unintuitive Funktionen, die manchmal im Forum herausgefunden werden, so wandte ich mich an das Standardbeispiel). SocketTlsHandshake habe ich ausprobiert - es gibt immer false in allen Bedingungen zurück und hat keinen Einfluss auf die Problemlösung. Da die Zertifikatsdaten zurückgegeben werden, wird der Handshake durchgeführt. Sogar der Header, der Länge nach zu urteilen, kommt an, aber er kehrt einfach nicht zum MQL-Code zurück. Der Fehlercode ist zu allgemein gehalten und der Fehler selbst ist fragwürdig. Wir brauchen eine Insiderperspektive.

Die Funktion SocketTlsHandshake muss nicht verwendet werden, wenn die Verbindung zunächst sicher ist ("https://" oder Port 443 oder 465)

Die Funktion wird in besonderen Fällen/Protokollen verwendet

 
Ilyas:

SocketTlsHandshake muss nicht verwendet werden, wenn die Verbindung zunächst gesichert ist ("https://" oder Port 443 oder 465)

Die Funktion wird in besonderen Fällen/Protokollen verwendet

Ich benutze es nicht. Der Code zur Reproduktion des Problems ist beigefügt.

 
Stanislav Korotky:

Ich benutze es nicht. Der Code zur Reproduktion des Problems ist beigefügt.

Ersetzen Sie SocketTlsRead durch SocketTlsReadAvailable

 
Ilyas:

Ersetzen Sie SocketTlsRead durch SocketTlsReadAvailable

Können Sie das genauer erläutern? In der Beispieldokumentation wurde SocketTlsRead verwendet. Warum wurde dort nicht SocketTlsReadAvailable verwendet?

Wann sollte ich eine Funktion verwenden und wann eine andere?

Wie schreibt man universellen Code zum Blockieren eines Lesevorgangs von einem Socket, der sowohl für geschützte als auch für ungeschützte Verbindungen geeignet ist - wir haben die Funktion SocketReadAvailable nicht, oder?

PS. Die Funktion wurde geändert. Der Fehler ist nicht verschwunden. Hier ist der aktualisierte Code. GetLastError gibt 0 zurück.

Dateien:
SocketExample.mq5  4 kb
 

Im visuellen Testerwird der Aufruf der FunktionCopyTicksRange vom Indikatormit dem Fehler 4014 (ERR_FUNCTION_NOT_ALLOWED) beendet.

Derselbe Indikator funktioniert online auf demselben Instrument einwandfrei. Wo liegt das Problem? Ist diese Funktion im Prüfgerät verboten? Ich habe in der Hilfe keinen Hinweis darauf gefunden.

 
Stanislav Korotky:

Im visuellen Testerwird der Aufruf der FunktionCopyTicksRange vom Indikatormit dem Fehler 4014 (ERR_FUNCTION_NOT_ALLOWED) beendet.

Derselbe Indikator funktioniert online auf demselben Instrument einwandfrei. Wo liegt das Problem? Ist diese Funktion im Prüfgerät verboten? Ich habe sie in der Hilfe nicht gefunden.

Prüfung durch echte Zecken?

 
Stanislav Korotky:
Genau, das ist nicht mein Code, sondern aus dem Beispiel der Entwickler (Sockets von MQ haben einige unintuitive Funktionen, die manchmal im Forum herausgefunden werden, so wandte ich mich an das Standardbeispiel). Ich habe SocketTlsHandshake versucht - es gibt immer false in allen Bedingungen zurück und hat keine Auswirkung auf die Problemlösung. Da die Zertifikatsdaten zurückgegeben werden, wird der Handshake durchgeführt. Sogar der Header, der Länge nach zu urteilen, kommt, aber er kehrt einfach nicht zum MQL-Code zurück. Der Fehlercode ist zu allgemein gehalten und der Fehler selbst ist fragwürdig. Wir brauchen eine Insiderperspektive.

Ja, ich war auch überrascht, dass ohne SocketTlsHandshake das Zertifikat zurückgegeben wird.
Aber mit der Funktion SocketTlsHandshake wird der Fehler aufgerufen.
Es gibt eine Art implizite Logik in diesem Verhalten.

if(SocketConnect(socket, Address, Port, 5000) && SocketTlsHandshake(socket, Address))
Can't connect to echo.websocket.org:443, error 5274

UPD:
Die Empfehlung von Ilyas ist gesehen worden.
Ja, ohne diese Funktion gibt es keine Probleme mit der Verbindung.
Das Problem ist das Lesen.
 
Ilyas:

Ersetzen Sie SocketTlsRead durch SocketTlsReadAvailable

Ich habe den gleichen Ersatz mit SocketTlsReadAvailable versucht

int rsp_len; 

if(ExtTLS)
   rsp_len = SocketTlsReadAvailable(socket, rsp, len); 
   //rsp_len = SocketTlsRead(socket, rsp, len);
else
   rsp_len = SocketRead(socket, rsp, len, timeout);

Das Verhalten ist dasselbe wie beiSocketTlsRead

UPD:
Das gleiche Problem tritt auf, wenn SocketTlsHandshake auf einem anderen Port verwendet wird.

1...270027012702270327042705270627072708270927102711271227132714...3184
Neuer Kommentar