Errori, bug, domande - pagina 2707

 
Sergey Dzyublik:

Per favore gli sviluppatori(@Ilyas) prestano attenzione al bug rilevato.
Bug MT5 (build 2377) quando si seleziona una funzione sovraccaricata adatta per un argomento di tipo puntatore, la funzione con conversione di tipo in puntatore alla classemadre invece che alla classe base diventa più prioritaria.
Inoltre nessun errore di compilazione quando il puntatore alla classe base viene assegnato al puntatore alla classe madre.

Possibile bug correlato: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
}

Grazie per il messaggio.

Corretto da

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


Rimane così com'è - questo codice può risultare dalla specializzazione dei template (in una parte che non funzionerà, ma influenzerà la compilazione).

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

Sì, infatti nel tuo codice, sulla porta 80 viene restituita l'intestazione, sulla 443 no.
Ho rivisto il tuo codice e non ho visto la funzione SocketTlsHandshake.
Il tuo codice non fa una stretta di mano. Questa può essere la ragione.
Anche se l'aiuto per questa funzione dice che non è richiesta se ci si connette alla porta 443.

Esattamente, questo non è il mio codice, ma l'esempio degli sviluppatori (i socket di MQ hanno alcune caratteristiche poco intuitive che a volte si capiscono sul forum, quindi mi sono rivolto all'esempio standard). Ho provato SocketTlsHandshake - restituisce sempre false in tutte le condizioni e non ha alcun effetto sulla risoluzione dei problemi. Poiché i dati del certificato vengono restituiti, l'handshake va avanti. Anche l'intestazione, a giudicare dalla sua lunghezza, arriva ma non torna al codice MQL. Il codice di errore è troppo generico e l'errore stesso è discutibile. Abbiamo bisogno di una visione dall'interno.
 
Stanislav Korotky:
Esattamente, questo non è il mio codice, ma dall'esempio degli sviluppatori (i socket di MQ hanno alcune caratteristiche poco intuitive, che vengono capite a volte nel forum, quindi mi sono rivolto all'esempio standard). Ho provato SocketTlsHandshake - restituisce sempre false in tutte le condizioni e non ha effetto sulla soluzione. Poiché i dati del certificato vengono restituiti, l'handshake va avanti. Anche l'intestazione, a giudicare dalla sua lunghezza, arriva, ma proprio non torna al codice MQL. Il codice di errore è troppo generico e l'errore stesso è discutibile. Abbiamo bisogno di una visione dall'interno.

Non c'è bisogno di usare la funzione SocketTlsHandshake se la connessione è inizialmente sicura ("https://" o porta 443 o 465)

La funzione è usata in casi/protocolli speciali

 
Ilyas:

SocketTlsHandshake non ha bisogno di essere usato se la connessione è inizialmente protetta ("https://" o porta 443 o 465)

La funzione è usata in casi/protocolli speciali

Non lo uso. Il codice per riprodurre il problema è allegato.

 
Stanislav Korotky:

Non lo uso. Il codice per riprodurre il problema è allegato.

Sostituire SocketTlsRead con SocketTlsReadAvailable

 
Ilyas:

Sostituire SocketTlsRead con SocketTlsReadAvailable

Puoi essere più specifico? Nella documentazione dell'esempio è stato usato SocketTlsRead. Perché non è stato usato SocketTlsReadAvailable?

Quando dovrei usare una funzione e quando un'altra?

Come scrivere codice universale per bloccare una lettura da un socket, adatto sia a connessioni protette che non protette - non abbiamo la funzione SocketReadAvailable, vero?

PS. Cambiata la funzione. L'errore non è scomparso. Ecco il codice aggiornato. GetLastError restituisce 0.

File:
 

Nel tester visivo, la chiamata della funzioneCopyTicksRange dall'indicatoretermina con l'errore 4014 (ERR_FUNCTION_NOT_ALLOWED).

Lo stesso indicatore funziona bene online sullo stesso strumento. Qual è il problema? Questa funzione è proibita nel tester? Non ho trovato alcuna menzione di questo nell'aiuto.

 
Stanislav Korotky:

Nel tester visivo, la chiamata della funzioneCopyTicksRange dall'indicatoretermina con l'errore 4014 (ERR_FUNCTION_NOT_ALLOWED).

Lo stesso indicatore funziona bene online sullo stesso strumento. Qual è il problema? Questa funzione è proibita nel tester? Non l'ho trovato nell'aiuto.

Test con zecche vere?

 
Stanislav Korotky:
Esattamente, questo non è il mio codice, ma dall'esempio degli sviluppatori (i socket di MQ hanno alcune caratteristiche poco intuitive che a volte vengono capite nel forum, quindi mi sono rivolto all'esempio standard). Ho provato SocketTlsHandshake - restituisce sempre false in tutte le condizioni e non ha alcun effetto sulla risoluzione del problema. Poiché i dati del certificato vengono restituiti, l'handshake va avanti. Anche l'intestazione, a giudicare dalla sua lunghezza, arriva, ma proprio non torna al codice MQL. Il codice di errore è troppo generico e l'errore stesso è discutibile. Abbiamo bisogno di una visione dall'interno.

Sì, anch'io sono rimasto sorpreso che senza SocketTlsHandshake il certificato venga restituito.
Ma con la funzione SocketTlsHandshake, chiama l'errore.
C'è una sorta di logica implicita nel comportamento.

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

UPD:
La raccomandazione di Ilyas è stata vista.
Sì, senza questa caratteristica, non ci sono problemi di connessione.
Il problema è la lettura.
 
Ilyas:

Sostituire SocketTlsRead con SocketTlsReadAvailable

Ho provato la stessa sostituzione con SocketTlsReadAvailable

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);

Il comportamento è lo stesso diSocketTlsRead

UPD:
Lo stesso problema esiste quando si usa SocketTlsHandshake su una porta diversa.