私は何をするのかを尋ねる質問 (このようなもの) を見つけました[[carries_dependency]]が、それは私がここで尋ねていることではありません。
私が読んだすべての回答は、このコードをどこにでも貼り付けることができ、魔法のように同等またはより高速なコードを取得できるように聞こえるため、いつ使用してはならないかを知りたいです。コメントの 1 つは、コードは同等または遅くなる可能性があると述べましたが、投稿者は詳しく説明しませんでした。
これを使用する適切な場所は、ポインターまたは参照であり、呼び出し元のスレッド内で渡されるか返される関数の戻り値またはパラメーターであると思います。コールバックまたはスレッドのエントリポイントでは使用しないでください。
誰かが私の理解についてコメントし、一般的に、それをいつ、いつ使用しないかについて詳しく説明できますか?
編集：他の読者が興味を持っている場合、この主題に関する本があることを私は知っています。私の答えが含まれているかもしれませんが、まだ読む機会がありません。
私が読んだすべての答えは、このコードをどこにでも貼り付けることができ、魔法のように同等またはより高速なコードを取得できるように聞こえるためです
より高速なコードを取得できる唯一の方法は、その注釈でフェンスの省略が許可されている場合です。
したがって、それが役立つ可能性がある唯一のケースは次のとおりです。
これは、かなり高速なコードを取得するために必要な一連の条件です。
(そして、C++ コミュニティの最近の傾向は、すべての場合に安全な適切なコンパイル スキームを発明することをあきらめ、ユーザーがコンパイラに値を「消費」するコードを生成するように指示するためのまったく異なる方法を考え出すことです。より明示的で単純に翻訳可能な C++ コードです。)
コメントの 1 つは、コードは同等または遅くなる可能性があると述べましたが、投稿者は詳しく説明しませんでした。
もちろん、ランダムにプログラムに付けることができる種類の注釈は、一般的にコードをより効率的にすることはできません! それはあまりにも簡単で、自己矛盾にもなります。
注釈がコードの制約を指定している、つまりコンパイラに対する約束であり、コード内の保証に対応しない場所 ( noexceptC++、 C など) に注釈を配置できないかrestrict、壊れるさまざまな方法でコードを作成します (noexcept関数内の例外はプログラムを停止させます。制限されたポインターのエイリアシングは、おかしな誤コンパイルや悪い動作を引き起こす可能性があります (以前は、その場合の動作は定義されていませんでした)。その後、コンパイラーはそれを使用して、特定の方法でコードを最適化できます)。 .
または、その注釈はコードをまったく制約せず、コンパイラは何も期待できず、注釈はこれ以上最適化の機会を作成しません。
場合によっては、注釈でプログラムを壊すことなくより効率的なコードを取得できる場合、他の場合には効率の悪いコードを取得する必要があります。これは一般的に当てはまり、消費セマンティックでは特に当てはまり、C++ コンストラクトの変換に前述の制約が課せられます。
これを使用する適切な場所は、ポインターまたは参照であり、呼び出しスレッド内で渡されるか返される関数の戻り値またはパラメーターであると思います
いいえ、それが役立つ可能性がある唯一のケースは、意図した呼び出し関数がおそらくメモリ消費順序を使用する場合です。