"ダミー "からの質問 - ページ 127

[Vladimir Gomonov]

Renat:

拝啓、文脈をよく見てください。

1) 管理された安全な環境から、全く管理されていない生バッファに飛び込む場合、そのバイナリ環境との互換性に責任を持つのは自分自身である。

2) コードを書いたら、そのコードのアーキテクチャに責任がある。また、構造が違うのに「馬と雌鹿を同じ荷車に乗せるのは難しい」と泣き言を言わないことです。

3) CLBufferRead と CLBufferWrite の説明を読むことをお勧めします。普遍的な void* 参照のおかげで、OpenCL にどんなタイプの参照でも渡すことができます。そして、オフセットやサイズもあります。

1.私はこの責任を負う覚悟がある。// 笑いをこらえて、ネクタイを調整する。

2.泣かないすでに言語として存在しているような2次元、3次元の配列を自分で書くのはバカバカしいだけです。そして、そうしなければならないのです。

3.確認します。旧バージョンでは、2次元配列の受け渡しがうまくいきませんでした。古い記憶で新しいものでは試していない。

// ArrrayCopy() にも void があるようですが、これはぬいぐるみで、次元ではなく、配列の型にのみ適用されます。

3点目を確認しに行った。

[Renat Fatkhullin]

泣きながら欠点を責めている。だから、道化になる必要はない。

多次元配列について。

• 多次元配列が機能する。
• OOPを使用し、クラス内に配列を保持・隠蔽する。
• 多次元配列のパラメータ渡しをより合理的にした。
  
• 構造体を積極的に利用することで、生活と制御がより簡単になり、複雑さが軽減されます。
  

すぐに、より簡単に、より正しくできるようになります。

[Vladimir Gomonov]

Renat:

泣きながら欠点を責めている。だから、道化になる必要はない。

多次元配列について。

• 多次元配列が機能する。
• OOPを使用し、クラス内に配列を保持・隠蔽する。
• 多次元配列のパラメータ渡しの不合理さを解消
  
• 構造体を積極的に利用することで、生活と制御がより簡単になり、複雑さが軽減されます。
  

すぐに楽になり、正しく使えるようになります。

そして、私の不満は、（例えば）このコードが前のバージョンでは動かなかったので、十分に根拠のあるものでした。

void gpuCalculate()
  {
//   for(int i=0; i<CountPass; i++) {for(int j=0; j<CountInd; j++) {nets[i*CountInd+j]=NETs[i][j];}}
//   CLBufferWrite(cl_Mem_NET,nets);
   CLBufferWrite(cl_Mem_NET,NETs);
   CLExecute(cl_Krn,1,Offs,Works);
   CLBufferRead(cl_Mem_Result,Result);
//   CLBufferRead(cl_Mem_NET,nets);
   CLBufferRead(cl_Mem_NET,NETs);
//   for(int i=0; i<CountPass; i++) {for(int j=0; j<CountInd; j++) {NETs[i][j]=nets[i*CountInd+j];}}
  }

そして、各処理ループで2回、配列を冗長に書き換える必要がありました（コメント付きコード参照）。

別のバージョンでは、（Nikolaiのように）仮想的に自分のオブジェクト配列を作りましたが、使い方が不器用です（特に遺伝子を書くとき）-関数構文はところどころで疲れます。

これでコードが動作し、2次元配列が実際にバッファに書き込まれるようになりました。これは進歩です。:)

OK、Peace、Friendship、Gum...。:) 演算子のオーバーロードをするのであれば、自分で構文を修正しますよ。

[Renat Fatkhullin]

演算子のオーバーロードはすでに行われ、次のビルドで利用できるようになります。

[Vladimir Gomonov]

Renat:
演算子のオーバーロードはすでに完了し、次のビルドで利用可能になる予定です。

わー！！！いい感じですね。

開発チームの皆さん、ありがとうございました。

これで、本当にいいコードが書けるようになる。

[Mykola Demko]

Renat:
演算子のオーバーロードはすでに行われており、次のビルドで利用可能になる予定です。

なぜこんなに小さな文字なのか？ という疑問がわきますね。

こんな感じでいい。

Перегрузку операторов уже сделали, будет доступно в следующем билде.

[Anatoli Kazharski]

オペレーターの過負荷というのは、私にとって新しい概念です。ここに詳しい説明がありました： http://programmersclub.ru/24/

これかな？

[Mykola Demko]

tol64:

オペレーターの過負荷というのは、私にとって新しい概念です。ここに詳しい説明がありました： http://programmersclub.ru/24/

これかな？

はい、そうです。

[Vladimir Gomonov]

Urain:

なぜこんなに小さな文字なのか？ という疑問がわきますね。その方がいいんです。

Перегрузку операторов уже сделали, будет доступно в следующем билде.

そうですね、とても荘厳な作りになりそうです。

:)

[Vladimir Gomonov]

Renat:

描写が重なることに気づかれたくなかったのでは？

typedef Int8 = int[8];
struct   Int8 { int arr[8]; };

2つ目の選択肢は、よりクリーンでパワフル、そしてよりコントロールしやすいものです。既存の方法で別の弱い存在を発明しても、共鳴することはない。

第2版の記述は問題ない。問題は、使っても 構文が良い方向に変化しないことです。

そこで、強力かつ安全な 妥協案として、「デフォルト」フィールドを提案します。 デフォルトというキーワードは、構文の違いを完全に解決してくれます。:)

この場合

struct   Int8 
  { 
    int arr[8]; default;
  };

(C++がそう、C#がそう、Delphiがそう、など）。

つまり、このようなフィールドにアクセスする場合、Int8Var.arr[i]の代わりにInt8Var[i]と書けば、コンパイラは正しく理解することができるのです。

// そして、肝心なのは、クラスだけでなく、構造体に対してもこれを行うことを忘れないことです。:)