問題タブ [carries-dependency]

誰かがそれを単なる人間が理解できる言語で説明できますか？

[ dcl.attr.depend ]/1で、次のように読みました。

属性[...] [...] は、関数宣言またはラムダの acarries_dependencyに適用できます。この場合、パラメーターの初期化が (1.10) 各左辺値から右辺値への依存関係を運ぶことを指定します。そのオブジェクトの変換 (4.1)。この属性は、関数宣言の に適用することもできます。この場合、戻り値があれば、それが関数呼び出し式の評価に依存することを指定します。declarator-idparameter-declarationdeclarator-id

私が見逃しているのは、属性を暗黙的thisなパラメーターに適用する方法です。

例として、次の free 関数を考えてみましょう。

そしてそれは同等です（ただし、属性については）メンバーバージョン：

私は何をするのかを尋ねる質問 (このようなもの) を見つけました[[carries_dependency]]が、それは私がここで尋ねていることではありません。

私が読んだすべての回答は、このコードをどこにでも貼り付けることができ、魔法のように同等またはより高速なコードを取得できるように聞こえるため、いつ使用してはならないかを知りたいです。コメントの 1 つは、コードは同等または遅くなる可能性があると述べましたが、投稿者は詳しく説明しませんでした。

これを使用する適切な場所は、ポインターまたは参照であり、呼び出し元のスレッド内で渡されるか返される関数の戻り値またはパラメーターであると思います。コールバックまたはスレッドのエントリポイントでは使用しないでください。

誰かが私の理解についてコメントし、一般的に、それをいつ、いつ使用しないかについて詳しく説明できますか?

編集：他の読者が興味を持っている場合、この主題に関する本があることを私は知っています。私の答えが含まれているかもしれませんが、まだ読む機会がありません。

このSO投稿で [[carries_dependency]] について読んでいました。

しかし、私が理解できなかったのは、受け入れられた回答の以下の文です:

「特に、memory_order_consume で読み取られた値が関数に渡され、[[carries_dependency]] がない場合、適切なメモリ順序付けセマンティクスが維持されることを保証するために、コンパイラはメモリ フェンス命令を発行する必要がある場合があります。パラメータが[[carries_dependency]] で注釈が付けられている場合、コンパイラは関数本体が依存関係を正しく運ぶと想定でき、このフェンスは不要になる可能性があります。

同様に、関数が memory_order_consume でロードされた値、またはそのような値から派生した値を返す場合、[[carries_dependency]] がない場合、適切なメモリ順序付けセマンティクスが維持されることを保証するために、コンパイラはフェンス命令を挿入する必要がある場合があります。[[carries_dependency]] アノテーションを使用すると、呼び出し元が依存関係ツリーの維持を担当するようになるため、このフェンスは不要になる可能性があります。」

それを一歩一歩見てみましょう：

「memory_order_consumeで読み取られた値が関数に渡された場合、[[carries_dependency]]なしで、コンパイラはメモリフェンス命令を発行して、適切なメモリ順序セマンティクスが維持されることを保証する必要があります。」

そのため、アトミック変数がパラメータとして関数に渡されるときのリリース消費メモリ モデルのアトミック変数の場合、コンパイラはフェンス ハードウェア命令を導入して、関数に提供されるアトミック変数の最新の更新された値を常に持つようにします。

次 -

「パラメーターに [[carries_dependency]] の注釈が付けられている場合、コンパイラーは関数本体が依存関係を正しく運ぶと想定でき、このフェンスは不要になる可能性があります。」

これは私を混乱させます-アトミック変数の値はすでに消費されており、関数はどの依存関係を持っていますか?

同様に -

「関数がmemory_order_consumeでロードされた値、またはそのような値から派生した値を返す場合、[[carries_dependency]]なしでは、適切なメモリ順序付けセマンティクスが維持されることを保証するために、コンパイラはフェンス命令を挿入する必要がある場合があります。 [[呼び出し元が依存関係ツリーを維持する責任を負うようになったため、このフェンスは不要になる可能性があります。」

例から、依存関係の実行について何を言おうとしているのか明確ではありませんか?

C++ 標準によると、次のようになります。

評価 A は、次の場合に評価 B に依存します。 - A の値が B のオペランドとして使用されます。

— B は std::kill_dependency (29.3) の特殊化の呼び出し、または

— A は組み込みの論理 AND (&&、5.14 を参照) または論理 OR (||、5.15 を参照) 演算子の左オペランド、または

— A が条件 (?:、5.16 を参照) 演算子の左オペランド、または

— A は、組み込みのコンマ (,) 演算子 (5.18) の左オペランドです。(...)

関係の前に順序付けされた依存関係が kill_dependency 呼び出しで停止する理由は理解できますが、論理 AND、OR、コンマなどの演算子も依存関係チェーンを壊すのはなぜですか?

以下のコードには未定義の動作があるということですか?