問題タブ [restrict-qualifier]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - GCC C ++コンパイラは__restrict-ステートメントを考慮しますか?
GCCコンパイラを介してコンパイルするときに、C++コード内の特定のポインタを__制限することの影響を調査しました。
ランタイムがまったく同じであるだけでなく、実行可能ファイルも変更されていないようで、バイト単位のサイズは以前とまったく同じであることが判明しました。
私のGCCバージョンは
また、解析時にこのC ++拡張機能を受け入れますが、コードをアセンブルするときにそれを考慮していないようです。したがって、理由があるか、コンパイラがこのセマンティック情報の使用方法を知らないか、この情報の処理が完全に無効になっています。
このコードは多くの数値計算を実行します。テスト目的で有効にしたいと考えています。手伝ってくれますか?
c - 制限されたポインタの質問
制限付きポインタに関する規則について少し混乱しています。多分そこに誰かが私を助けることができます。
ネストされた制限付きポインターを次のように定義することは合法ですか?
/li>次のように制限付きポインタ値を導出することは合法ですか?
/li>
ありがとう!アンドリュー
c - 制限されたポインタの割り当て
制限されたポインタの割り当てについて質問があります。特定の質問については、コードのコメントを参照してください。全体として、restrictで何が合法か疑問に思っています(標準を読みましたが、まだ質問があります:-(
ご協力いただきありがとうございます!
c - これは制限ポインタの無効な使用ですか?
インデックスを計算して2番目の関数に渡す大きな配列があるとします。簡単な例として、次のようなものがあります。
これは、配列の一部のアドレスを foo() に渡す、bar() 内の配列の一部のエイリアスを実際に使用したことがない場合でも、bar() の制限の規則に違反していますか?
c - Cで制限ポインタを使用する場合、初期識別子を使用して変数を変更しても問題ありませんか?
C で Pointerを使用する場合、最初のIdentifierrestrict
を使用して変数を変更しても問題ありませんか? 例えば:
... fooPtrが作成された後、fooを介してfooの値を変更しました。restrict
パート 1は問題ないように見えます。パート 2について混乱しています。そして、私が理解していることからrestrict
、パート3は悪いです(コンパイラはそれを許可しますが、その動作は未定義であり、そうしないのはプログラマ次第です)。
c - C typedef で制限する
私は今いくつかのコードを実行していますが、restrict キーワードを使用して問題が発生しました。
a と b を制限したい場合はどうすればよいですか? 以下のコードは失敗しました:
前もって感謝します。
c - __restrict キーワードの可用性を確認する良い方法は何ですか?
GCC と Visual Studio#ifdef
のキーワードが使用可能かどうかを確認するために、 のセットを探しています。__restrict
コンパイラのバージョンを確認する必要があると思いますが、どのバージョンで導入されたのかわかりません。私を助けてくれる人はいますか?
更新: これは、C89 としてコンパイルするときに動作する必要があります (動作する必要があるだけです)。__STDC_VERSION__
したがって、C99 または C99 のサポートを示すことに頼ることはできません。
c++ - 2 つのオブジェクト内部のエイリアシングを防止する
これに似た関数シグネチャがあります
内部的に、マトリックス クラスにはコンポーネントfloat* data;
を表す がありm x n
ます。a
コンパイラにそれを伝え、出力行列にエイリアスを設定しb
ないようにして、大量のロードストアを実行しないようにしたいと思います。
どうすればそれを行うことができますか?関数シグネチャへのポインターを渡して__restrict
(MSVC で) ポインターをマークできることはわかっていますが、オブジェクトにメモリへのポインターが含まれている参照渡しオブジェクトのイディオムを保持したいと思います。
__restrict
また、オブジェクト参照では機能しないことも知っています。
c - C99:スレッドセーフを文書化するための制限されたポインタ?
この質問は、制限付きの技術的な使用法ではなく、主観的な使用法に関するものです。技術的に制限がどのように機能するかについては誤解されているかもしれませんが、その場合は、誤った前提に基づいて質問をするために私をグリルしてください。
これまでのところ、restrictedを使用している2つの例を次に示します。
不変の文字のシーケンスへのポインターを受け取る関数がある場合、他の人が関数の実行と同時に、たとえば別の並列から、自分のポインターを介してデータにアクセスできるため、制限されているとは言えません。スレッド。データは変更されていないので、問題ありません。
ただし、関数が変更する可能性のある一連の可変文字へのポインターを取得する場合、潜在的に一貫性のないデータによる関数。また、データが変更される可能性も記載されているため、コーダーは古いデータを読み取らないこと、およびアクセスするときなどにメモリバリアを使用する必要があることを認識しています...
私はあまりCをコーディングしていないので、ここで想定していることについて簡単に間違っている可能性があります。これはrestrictの正しい使用法ですか?このシナリオで行う価値はありますか?
また、関数が戻ったときに制限付きポインターがスタックからポップされると、他のポインターを介してデータに自由にアクセスできるようになり、制限は制限付きポインターの間だけ続くと想定しています。「非公式」ポインターを介して制限されたデータにアクセスするのはUBであるため、これはルールに従ったコーダーに依存していることを私は知っています。
私はこれをすべて正しく理解しましたか?
編集:
ユーザーが複数のスレッドを介してデータにアクセスするのを妨げることはまったくないことをすでに知っていることを明確にしておきたいと思います。また、C89には「スレッド」が何であるかさえ知らないことも知っています。
ただし、参照を介して引数を変更できるコンテキストを考えると、関数の実行中に引数にアクセスしてはならないことは明らかです。これはスレッドセーフを強制するために何もしませんが、あなた自身のリスクで関数の実行中にあなた自身のポインタを介してデータを変更することを明確に文書化します。
スレッド化が完全に方程式から外されたとしても、それが私にとって正しいと思われるシナリオでは、さらに最適化することができます。
それでも、これまでのすべての信頼できる回答に感謝します。気に入ったすべての回答に賛成しますか、それとも受け入れた回答だけに賛成しますか?複数が受け入れられた場合はどうなりますか?申し訳ありませんが、私はここで新しいです、私は今FAQをより徹底的に調べます...
c++ - メンバー関数の修飾子を制限する (このポインターを制限する)
注:明確にするために、質問はrestrict
一般的なキーワードの使用に関するものではなく、具体的にはここで説明されているメンバー関数への適用に関するものです。
gcc を使用すると、__restrict__
(C99 の に相当する GNU++ のrestrict
) 修飾子をメンバー関数でthis
使用でき、関数のスコープ内で限定修飾ポインターを効果的に作成できます。牛肉はどこ?
ほとんどのメンバー関数は他のメンバーで動作しthis
、 を介してアクセスしますT* const
(通常はエイリアスされていません)。エイリアスされる可能性があるためthis
、メンバー関数内で何らかの形で使用されている型への 2 番目のポインターが必要であり、それはどこかから取得する必要があります。
これは、たとえば、すべての二項演算子や、少なくとも 2 つのポインターまたは同一の非自明な型の参照を取るその他の自由関数など、非メンバー関数の場合によくある状況です。ただし、これらの関数には がないthis
ため、関係ありません。
代入演算子、コピー コンストラクター、および単項比較演算子は 、原則としてエイリアス化this
できるメンバー関数の例です (別のオブジェクトが参照を介して渡されるため)。したがって、これらに restrict 修飾子を割り当てることは本当に意味があります。コンパイラーにとっては、他のすべての関数が restrict プロパティを持っていることはすでに明らかなはずです (T への 2 番目のポインターが存在しないため)。
たとえば、restrict
onを使用したoperator=
場合、結果として自己割り当てをまったくチェックしないでください。これthis
は、その関数のスコープ内でエイリアス化されていないと言っているためです ( true の場合、自己割り当ては発生しない可能性があります)。
明らかに、これは事前に知ることができないものであり、意味をなさないものでもあります.
では、実際にメンバー関数に制限修飾子を与えたい場合と、それが理にかなっているのはどのような場合でしょうか?