手動で管理されたメモリへのポインタを持つ構造体を実装しています。DMD ではすべて問題なく動作しますが、GDC でテストすると、opEqualsオペレーターの過負荷で失敗します。memcmpに絞り込みました。ではopEquals、指定されたメモリを memcmp と比較します。memcmp は、DMD では期待どおりに動作しますが、GDC では失敗します。
戻って、組み込み型opEqualsを使用して、手動で管理されたメモリに格納されている各値を一度に 1 つずつ比較してメソッドを作成すると==、両方のコンパイラで機能します。私は memcmp ルートを好みます。なぜなら、書くのに時間がかからず、より高速であるように思われるからです (インダイレクションや反復が少ないなど)。
なんで？これはバグですか？
(C での私の経験は 10 年前で、それ以来 python/java を使用していました。C でこの種の問題は一度もありませんでしたが、あまり使用していませんでした。)
編集：
比較しているメモリは、「実際の」値の 2 次元配列を表しています。これを 1 つのチャンクに割り当てたいだけだったので、ギザギザの配列を扱う必要はありませんでした。タイトなループで構造体を多用します。基本的に、頻繁に使用される値 (トレース、行列式) を (最終的に) キャッシュし、コピーを必要としない代替の読み取り専用ビューを転置に提供する独自のマトリックス構造体を展開しています。約 10x10 から約 1000x1000 の行列を扱う予定です (常に正方形であるとは限りません)。
また、a を介して GC でメモリを割り当てるバージョンを実装しubyte[]、2 つの実装をプロファイリングする予定です。
編集2：
わかりました、私はいくつかのことを試しました。parallelループもいくつかあり、それが問題になる可能性があるという予感がしました。そこで、いくつかのバージョン ステートメントを追加して、並列バージョンと非並列バージョンを作成しました。GDC で動作させるには、非並列バージョンを使用してから に変更realする必要がありましたdouble。
GDC でコンパイルされたすべてのケース。しかし、単体テストは常に同じ回線で一貫して失敗したわけではなく、またはopEqualsを使用したときの呼び出しで一貫して失敗しました。DMD では、すべてのケースがコンパイルされ、問題なく実行されました。realparallel
ありがとう、