MQLによる非同期・マルチスレッドプログラミング - ページ 35

新しいコメント
 
Andrei Novichkov:

実際にドキュメントでフラグについて読んでみてはいかがでしょうか。https://en.cppreference.com で .また、stackoverflow.comでのディスカッションを含む例もあります。私は普段からこれらの情報源を利用しているので、皆さんもそうすることをお勧めします。

では、なぜ自分の言葉に責任を持たないのに、会話に参加しようとするのでしょうか？私は、ハンドブックの賢い人たちではなく、あなたの意見に興味があったのです。邪魔をするなあなたの指示がなくても、ドックを読むことができます。そして、1つのスレッドで関数を呼び 出すために、future/promise/asyncといった動物園のようなものは必要ない。

 
Vict:

自分の言ったことに答えないなら、なぜ会話に入ってくるのでしょうか？私は、ハンドブックの賢い人たちではなく、あなたの意見に興味があったのです。 邪魔をするなあなたの指示がなくても、ドックを読むことができます。そして、1つのスレッドで関数を呼び 出すために、future/promise/asyncといった動物園のようなものは必要ない。

意味不明なこと言ってますね。知らないのか、どこに情報があるのか言ったのに。そして、それは私の責任でした。もっと本と友達になりましょう。
 
Andrei Novichkov:
意味不明なこと言ってますね。知らないのか、どこに情報があるのか言ったのに。そして、それは私の責任でした。もっと本と友達になりましょう。

どうやらあなたもご存じないようですね。なぜ何も書かないのか？もしかしたら、私は知らないかもしれない、何が大変なのか？普通に意見を求めたら、どこかに飛ばされた。

ブラックリストに載った、同志よ。

 
Vict:

どうやらあなたもご存じないようですね。なぜ何も書かないのか？もしかしたら、私は知らないかもしれない、何が大変なのか？普通に意見を求めたら、どこかに行けと言われた。

ブラックリストに載った、同志よ。

どこにも送ってないし、考えもしなかったよ。そんな質問に自分の言葉ではうまく答えられないので、ドキュメントについて書いてみました。繰り返しになりますが、何を怒ることがあるのでしょうか？でも、お望み通り、黒、そう黒。
 
Andrei Novichkov:
私はあなたをどこにも送ってないし、そんなこと夢にも思ってない。このような質問に自分の言葉で答えるのは苦手なので、ドキュメントについて書いてみました。繰り返しになりますが、何をもって不快とするのか？ でも、お望み通り、黒、そう黒。

これに関するドキュメントはほとんど役に立ちません。

std::launch::deferred タスクの結果が最初に要求されたときに呼び出し側のスレッドで実行される (遅延評価)
なぜこのような奇跡が必要なのかよく理解できません。私は簡単に関数へのポインタを必要なスレッドに渡し、そこで非同期( std::launch::deferred) なしで計算することができます。
 
Vict:

なぜこのような奇跡が必要なのかよく理解できません。私は簡単に関数へのポインタを必要なスレッドに渡し、そこで非同期( std::launch::deferred) なしで計算することができます。

閑話休題

マイクロソフトの例題は、セルフドキュメント化されたコードとして書かれていることが多いので、拡張して最終的な値に置き換えることができる面倒な構成が書かれていることに気づいた（コードを見て、一発で分かったみたいな）)))

HH：C#の例では、残念ながらそうではありません。何度か、C#は実際にはC++の類似品で、OOPを使う 傾向があると信じて書きましたが、そうではなく、まったくC++ではないことがわかりました。多くの場合、基底クラスにキャストしないとクラスのフィールドに「到達」できず、そのため私は扱いにくい長い構文を使用しなければなりません。

 

注意：デフォルトでは、これら2つのフラグは一緒に適用されます deferred | async、これは開発者の責任を取り除くものです。ここではメインスレッド関数の話をしています。そう、関数へのポインタやファンクタなど、何でも引数として渡すことができるのです。また、遅延フラグは、関数の同期実行を意味することもあります。ほら、言ったでしょ、こういう質問に自分の言葉で答えるのが苦手なんです（笑)。濁ってしまうんですね。通常、すべてをデフォルトのままにして、これらのフラグに悩まされることはありませんが、もしかしたらそれは正しくないかもしれません。

 
Igor Makanu:

HH: C#の例は、残念ながらそうではありません。何度か私は、C#は実際にはC++のアナログで、OOPの使用を 義務付ける傾向があると確信して書きましたが、そうではなく、まったくC++ではないことがわかりました。多くの場合、ベースクラスにキャストしないとクラスのフィールドに「アクセス」できず、長い面倒な構造を使用しなければなりません。

まあ、MSはSpursに関するドキュメントが非常に充実しています。すべて詳細に説明されています。文句のつけようがない。
 
Vict:

まあ、これに関するドキュメントはほとんど役に立ちませんが

なぜこのような奇跡が必要なのかよく理解できません。私は簡単に関数へのポインタを必要なスレッドに渡し、そこで非同期( std::launch::deferred) なしで計算することができます。
さて、例えば、スタック上にある現在のパラメータで値を計算する関数が必要だが、今ではなく、このスコープでもない。そこでstd::asincを作ったわけですが、ここで問題があります。パラメータのひとつはグローバル変数への 参照またはポインタですが、計算ではこの変数の現在の値ではなく、後で必要となる値が必要です。そのため、std::lounch::asincとstd::lounch::deferred bitmaskを作って、今は関数に値を渡し、後で計算 することができるようにしたわけです。
 
Vladimir Simakov:
例えば、スタックにある現在のパラメータで値を計算する関数が必要だが、今ではなく、このスコープでもない場合だ。そこでstd::asincを作ったわけですが、ここで問題があります。パラメータのひとつはグローバル変数への 参照またはポインタですが、計算にはこの変数の現在の値ではなく、後で必要となる値が必要です。そのため、std::lounch::asincとstd::lounch::deferred bitmasksを作って、今は関数に値を渡して後で計算を 行うことができるのです。

だから、asyncに渡す関数を受け取り、それに引数をバインドし、それを呼び出す（あるいは別のスレッドに送る）時まで保存しておくことができる。futureを格納するか、std::bind()の出力を格納するかで、どのような違いがあるのでしょうか？

私の頭に浮かぶ唯一の合理的な説明 - プール内の実行スレッド数に対する手動制御 (デフォルトの async|deferred を信用しない場合) - 例えば、システムがあまりにも忙しくなったら async フラグのジョブ送信を停止し、deferred を送信します。

一般的に、私はasync()の遅さに少し失望しています、私は独自の軽量スレッドプールを作成します、それははるかに高速になるように思えます。

1...28293031323334353637383940
新しいコメント