7

原則として、ハードコードされた型ではなくConst（型なし）パラメーターを利用することにより、ポインターを使用する際の多くの古典的な設計トラップを回避しました。これにより、技術的な詳細をコンパイラに任せながら、高度なグラフィカル関数を実行する際の速度が向上します。また、DelphiとFree Pascalで同じコードを最小限の変更で簡単に使用できるようになりましたが、最近、Delphiの進化に関するEmbarcaderoの大げさな発言と、今後の安全モデルのために、これに疑問を呈し始めました。

たとえば、次の例を考えてみましょう。

Type TSomeDataProc = procedure (const aInput;var aOutput) of Object;

(* Convert 8-bit pixel to 16-bit pixel *)
Procedure TMyClass.ProcessSomeData08x565(Const aInput;var aOutput);
var r,g,b: Byte;
Begin
  FPalette.ExportTriplets(Byte(aInput),r,g,b);
  Word(aOutput):=(R SHR 3) SHL 11 or (G SHR 2) SHL 5 or (B SHR 3);
End;

(* Convert 16-bit pixel to 24-bit pixel *)
Procedure TMyClass.ProcessSomeData565x888(Const aInput;var aOutput);
Begin
  With TRGBTriple(aOutput) do
  Begin
   rgbtRed:=(((word(aInput) and $F800) shr 11) shl 3);
   rgbtGreen:= (((word(aInput) and $07E0) shr 5) shl 2);
   rgbtBlue:= ((word(aInput) and $001f) shl 3);
  end;
End;

現在、同じ宣言を持つ2つのプロシージャがありますが、それらはピクセルデータを非常に異なる方法で処理します。これにより、ルックアップテーブルを使用して正しい「コンバーター」メソッドを取得できるという利点があります。これは、コンストラクターで、または次のように画像ビットマップが割り当てられている場所で実行する必要があります。

Private
FLookup: Array[pf8bit..pf32bit,pf8bit..pf32bit] of TSomeDataProc;

Procedure TMyClass.Create;
Begin
  Inherited;
  FLookup[pf8bit,pf16bit]:=ProcessSomeData08x565;
  FLookup[pf16bit,pf24Bit]:=ProcessSomeData565x888;
end;

ピクセルを変換する必要があるときはいつでも、正しい方法を調べてそれを使用するだけです。構文はすべてのプロシージャで同じです。したがって、各プロシージャが「どのように」動作するかを心配する必要はありません。私たちのクラスに関する限り、それらはすべて同じように見えます。

Procedure TMyClass.ConvertTo(aFormat:TpixelFormat);
Begin
 // Get function for the correct pixel converter
 FConvertProc:=FLookup[CurrentFormat,aFormat];

 //Use the pixel converter
 FConvertProc(GetSourcePixelAddr(x,y),GetTargetPixelAddr(x,y));
end;

問題は次のとおりです。この種の型キャスト（例：Const to Byteまたは定義されたレコードタイプ）は64ビットでも存続しますか？個人的にはその理由はわかりませんが、Embarcaderoは新しい「安全」モデルとポインターの使用に関して漠然としているため、将来のためにコードを保護するのは少し難しいと思います。

4

2 に答える 2

3

このようなトリックはRTLで使用されているため、多くのコードを解読せずにvarまたはconstタイプレスパラメーターを非推奨にすることはありません。

Embarcaderoは、可能な限り下位互換性を維持するために最善を尽くしています。

外部アセンブラの使用について最初に通知した後、64ビットコンパイラにインラインasmを含める必要があります。

そして、そのような変更は64ビットモデルとは何の関係もありませんが、x86-64アセンブラーは書くべき新しいコードでした。

したがって、Embarcaderoの公式ニュースグループにこの質問を投稿する必要がありますが、これについて心配する必要はないと思います。

于 2011-01-31T14:56:34.200 に答える
1

この場合ではありませんが、FPCはすでにCONSTパラメーターを変更していることに注意してください。

通常の場合、CONSTは、すべての呼び出し規約の参照によって保証されなくなりましたが、それぞれのABIが指定するものに従います。新しいパラメータタイプであるCONSTREFは、参照によるものであることが保証されています。

互換性のすべての破損と同様に、TP / DelphiではCONSTが常にrefによるものであるという問題がありますが、TP/Delphiも常にx86です。

特に、IUnknown.Queryinterfaceのように、すべてのSTDCALL関数が変更されます。

http://wiki.freepascal.org/User_Changes_Trunk#IInterface.QueryInterface.2C_._AddRef_and_._Release_definitions_have_been_changed

その理由は、多かれ少なかれ、これらの場合、x86 ABI情報が汎用インターフェイスに入ったためです。これは、アーキテクチャ間の互換性がありません。したがって、それが言語の一部なのか、それとも言語のx86実装の一部なのかを推測する必要があります。

IUnknownは、FirefoxのXPCOMなどの他のプラットフォームでも使用されることに注意してください。

Delphiもそのような障害にぶつかる可能性がありますが、ニーズに合わせて内部規則を変更することはできますが、他の世界を実際に変更することはできないため、明示的な呼び出し規約の要件を持つ関数/メソッドに主に影響を与えると思います（（XP） COMまたは既存のC（++）ライブラリ）Delphiの既存のコードに適合

于 2011-02-04T14:16:47.510 に答える