エラー、バグ、質問 - ページ 2707

新しいコメント
 
Sergey Dzyublik:

開発者(@Ilyas)は、検出されたバグに注意を払ってください。
MT5 (build 2377) で、ポインタ型の引数に対して適切なオーバーロード関数を選択すると、ベースクラスではなく親クラスへの ポインタに型変換される関数が優先されるバグ。
また、ベースクラスへのポインタが親クラスへのポインタに代入されても、コンパイル時のエラーは発生しません。

関連する可能性のあるバグ： 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
}

メッセージをありがとうございました。

修正方法

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


そのまま - このコードは、テンプレートの特殊化によって生じる可能性があります（動作しないがコンパイルに影響する部分）。

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

確かに、あなたのコードでは、ポート80ではヘッダーが返され、ポート443では返されません。
あなたのコードをもう一度見てみましたが、そこにはSocketTlsHandshake関数が見当たりませんでした。
あなたのコードではハンドシェイクが行われません。これが理由かもしれません。
この機能のヘルプには、443番ポートに接続する場合は不要と記載されていますが。

その通り、これは私のコードではなく、開発者の例です（MQからのソケットは、時々フォーラムで解明されるような直感的でない機能があるので、私は標準的な例に目を向けました）。 私はSocketTlsHandshakeを試してみました - それは常にすべての条件で偽を返し、問題解決には何の影響も与えませんでした。証明書データが返されるため、ハンドシェイクは成立する。ヘッダーも、その長さから判断して、届いているのですが、ただMQLのコードには戻ってきません。エラーコードが 汎用的すぎて、エラーそのものに疑問がある。内部からの視点が必要だ。
 
Stanislav Korotky:
その通り、これは私のコードではなく、開発者の例からのものです（MQからのソケットには直感的でない機能があり、それはフォーラムで時々解明されているので、私は標準の例に目を向けました）。 SocketTlsHandshakeを試しましたが、それはすべての条件で常にfalseを返し、問題解決に何の効果もありませんでした。証明書データが返されるため、ハンドシェイクは成立する。ヘッダーも、その長さから判断して、届いているのですが、ただMQLのコードには戻ってこないのです。エラーコードが 汎用的すぎて、エラーそのものに疑問がある。内部からの視点が必要だ。

初期状態で安全な接続（"https://"またはポート443または465）であれば、SocketTlsHandshake関数を使用する必要はありません。

この機能は、特殊なケース/プロトコルで使用されます。

 
Ilyas:

SocketTlsHandshakeは、接続が最初に保護されている場合（"https://"またはポート443または465）、使用する必要はありません。

この機能は、特殊なケース/プロトコルで使用されます。

使っていないこの問題を再現するためのコードを添付します。

 
Stanislav Korotky:

使っていないこの問題を再現するためのコードを添付します。

SocketTlsReadをSocketTlsReadAvailableに 置き換える。

 
Ilyas:

SocketTlsReadをSocketTlsReadAvailableに置き換える。

もう少し具体的に教えてください。サンプルドキュメントでは、SocketTlsReadが使用されています。なぜそこでSocketTlsReadAvailableが使われなかったのでしょうか？

ある機能を使うべきときと、別の機能を使うべきときとは？

保護された接続と保護されていない接続の両方に適した、ソケットからの読み込みをブロックする普遍的なコードを書く方法 -SocketReadAvailable関数は ありませんよね？

PS.機能を変更しました。エラーは消えなかった。以下は、更新されたコードです。GetLastErrorは0を返します。

ファイル:
SocketExample.mq5  4 kb
 

ビジュアルテスターでは、インジケーターからのCopyTicksRange 関数の呼び出しは、エラー4014（ERR_FUNCTION_NOT_ALLOWED）で終了 します。

同じインジケータが同じ楽器でオンラインでも問題なく動作しています。何が問題なのか？この機能はテスターで禁止されているのでしょうか？ヘルプに記載がありませんでした。

 
Stanislav Korotky:

ビジュアルテスターでは、インジケーターからのCopyTicksRange 関数の呼び出しは、エラー4014（ERR_FUNCTION_NOT_ALLOWED）で終了 します。

同じインジケータが同じ楽器でオンラインでも問題なく動作しています。何が問題なのか？この機能はテスターで禁止されているのでしょうか？ヘルプには載っていませんでした。

本物のダニによるテスト？

 
Stanislav Korotky:
その通り、これは私のコードではなく、開発者の例からです（MQからのソケットは直感的でない機能があり、時々フォーラムで解明されるので、私は標準の例に目を向けました）。 SocketTlsHandshakeを試しましたが、すべての条件で常に偽を返し、問題解決に何の効果もありません。証明書データが返されるため、ハンドシェイクは成立する。ヘッダーも、その長さから判断して、来るけど、ただ、MQLのコードに戻らないだけ。エラーコードが 汎用的すぎて、エラーそのものに疑問がある。内部からの視点が必要だ。

ええ、私もSocketTlsHandshakeなしで証明書が返されることに驚きました。
しかし、SocketTlsHandshake関数では、エラーを呼び出します。
その行動には、ある種の暗黙の論理があるのです。

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

UPDです。
イリヤスの推薦文が見られるようになった。
はい、この機能がなくても、接続に問題はありません。
問題は読書です。
 
Ilyas:

SocketTlsReadをSocketTlsReadAvailableに置き換える。

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

動作はSocketTlsReadと 同じです。

UPD:
SocketTlsHandshakeを別ポートで使用した場合も同様の問題が発生します。

1...270027012702270327042705270627072708270927102711271227132714...3185
新しいコメント