今日私はXE3で自分のXE3プロジェクトをコンパイルしようとしています。私が直面する最初の問題は、IndyのFTCPClient.Socket.ReadBytes()メソッドです。Delphi XE4 TBytesとTidBytesの間のIndyの互換性の問題
TBytesタイプを受け入れる前に、今はTidBytesを主張しています。
説明: TIdBytes = Byteの配列。 TBytes、Im私はそれがByteの配列であるTArrayのようなジェネリックなものだとは思わない。
質問番号1: なぜコンパイラは '[dcc32 Error] HistoricalStockData.pas(298):E2033実際のパラメータと正式なvarパラメータの型が同じである必要があります。私が見るとおり、彼らはすでに同じです。
質問番号2: 新しいデルファイバージョンでソースコードを変更する必要がありますか?
ありがとうございました。
同等のRTL型を使用するのではなく、独自の型を作成しているライブラリは、ゲットーにつながります。 Indyとそのバイト配列を使用し、バイト配列を使用して別のライブラリとやりとりするコードをどうやって書くことができますか? –
まず、RTLを変更したときにEmbarcaderoが自社製品の中断を止めるように指示します。 TBytesは単純な動的配列でした(今のところTIdBytesはそうです)。 RTTI、Object Inspector、コンパイラなどでうまくいきました。そして、TBytesをTArrayに変更し、そのすべてを破棄しました(Generics RTTIが悪い、C++のcodegenが悪いなど)。また、Indyは複数の言語をサポートしており、TArray はC++とDelphiでは異なる動作をすることに注意してください。そこで、TI dBytesを単純な動的配列に戻すための複数の理由がありました。私は軽く変更を加えなかったし、Embarcaderoでも私がその時にやるよう勧めた。 –
OK、私はあなたが変更する正当な理由があったと確信しています。 2013年にバイト配列を扱う方法についての議論がまだ残っていると私は間違っています。すべてのコードが 'TArray'を直接使用しているので、すべてのコードが一般的な型のための特別な型互換性の規則を楽しむことができます。したがって、理想的な世界では、「TBytes」も「TIdBytes」もなく、ライブラリは幸せに共存し、スムーズにやり取りすることができます。 –