問題タブ [pointer-arithmetic]
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++ - C++ は、ファイル内のすべてのポインター演算を検索します
大きな C++ ソース ファイルがいくつかあります。これらのファイルですべてのポインター算術演算を見つける必要があります。このタスクを自動的に行うことは可能ですか?
一部のコンパイラでポインタ演算を無効にして、エラーのリストを取得することは可能ですか?
c - 文字列を取得するための C のポインター演算
文字の配列の要素を取得したいのですが、まったく成功しません。問題は、最初と最後の要素のみを取得し、それ以上のものを取得しないことです。私のコードは次のとおりです。
助けはありますか?ありがとう
xcode - Xcodeでのvoid*警告の間接参照
私はこのSOの質問とこのSOの質問を知っています。これの目新しさの要素は、Xcodeに焦点を当てており、voidへのポインターを逆参照するために角かっこを使用しています。
次のプログラムは、Xcode 4.5.2では警告なしでコンパイルされ、GCC 4.2では警告付きでコンパイルされます。現在、Visual Studioを使用していなくても、これはコンパイラエラーと見なされることを覚えています。また、MSDNとインターネットは同意します。 。
メインの本体の3行目を次のように変更すると、次のようになります。
GCCとXcodeの両方で警告なしでコンパイルされます。
GDB、特にXcode / LLVMで、この沈黙を警告またはエラーに変える方法を知りたいです。これには、関数mainがintであるが、明示的に値を返さないという事実が含まれます(ちなみに、-Wallはトリックを実行しますGDB上)。
c++ - 偽装されたポインタ演算&(array [0])
今日、私はいくつかのソースコード(ソフトウェアフレームワークの使用を説明するサンプルファイルでした)を閲覧し、次のような多くのコードを発見しました。
つまり、基本的に、彼らは「アドレスにあるオブジェクトのアドレスを取得する」ことを実行しましたarray + x
。
array + 0
通常、これは、書くことやarray + 9
直接同じことをするので、明らかに愚かだと思います。私はいつもそのようなコードをsize_tforループに書き直しますが、それはスタイルの問題です。
しかし、これを使いすぎると、私は考えました。露骨に明白な何か、または言語の暗い隅に微妙に隠された何かが欠けているのでしょうか。
元のソースコードを見てみたい人は、それが厄介なものgoto
でmalloc
あり、もちろんこのポインタのことも含めて、オンラインで気軽に見てください。
c - ポインタ演算でのアクセス違反
コードで:
アクセス違反が発生するのはなぜですか? 何を変更すればよいですか?
c++ - 非配列型の「one-past-the-end」ポインタはC++で有効な概念ですか?
C++標準[秒5.7]は次のように述べています。
ポインタオペランドと結果の両方が同じ配列オブジェクトの要素を指している場合、または配列オブジェクトの最後の要素を1つ過ぎている場合、評価によってオーバーフローが発生することはありません。それ以外の場合、動作は定義されていません。
それで、配列以外のタイプのポインタが未定義であると仮定するのは正しいですか?
例えば:
上記のスニペットはコンパイルされ、(g ++で)問題なく動作しますが、それは有効ですか?
c - ポインタ アドレスの算術演算と 16 進数/10 進数の変換
extern char etext
、end
およびから取得したポインタ アドレスがありedata
ます。を使用して変数のアドレスも取得し&<Variable Name>
ました。どちらも 16 進数のポインター アドレスです。
これらのアドレスを 10 進数で計算する必要があります。どうすればいいですか?アドレスを 10 進数の int に変換する必要があるため、アドレスを差し引いてメモリ セグメントのサイズを確認できます。
c++ - 算術演算のポインタ関数に関連するエラー
これが私のエラーです:
最初の4つのエラーは何のためにあるのだろうかと思います。私はすべてのエラーを修正する必要がありますが、私は主に最初の4つについて心配しています。
プログラムは次のとおりです。
これは、接尾辞関数を取得して評価しようとしているだけです。
c - C ポインター演算および配列アクセス
構造体の配列へのポインターを取る関数があります
配列へのアクセス方法が少しずれているようです。
これを行うより良い方法はありますか?
c++ - サブオブジェクトの境界を越えたポインター演算
次のコード (サブオブジェクトの境界を越えてポインター演算を実行する) はT
、コンパイル対象の型 (C++11 では必ずしも POD である必要はありません) またはそのサブセットに対して明確に定義された動作を持っていますか?
LLVM は、最初は小さな配列にスタックを使用するように最適化されていますが、初期容量を超えるとヒープ割り当てバッファーに切り替える内部ベクター型の実装で、上記の手法のバリエーションを使用します。(このようにする理由は、この例からは明らかではありませんが、明らかにテンプレート コードの肥大化を減らすためです。これは、コードを調べればより明確になります。)
注:誰かが文句を言う前に、これはまさに彼らが行っていることではなく、彼らのアプローチは私がここで述べたものよりも標準に準拠している可能性がありますが、一般的なケースについてお尋ねしたいと思います.
明らかに、それは実際には機能しますが、標準の何かがそうであることを保証するかどうか興味があります. N3242/expr.addを考えると、私はノーと言う傾向があります:
同じ配列オブジェクトの要素への 2 つのポインターを減算すると、結果は 2 つの配列要素の添字の差になります...さらに、式 P が配列オブジェクトの要素または最後の要素の 1 つ後ろを指している場合式 Q が同じ配列オブジェクトの最後の要素を指している場合、式 ((Q)+1)-(P) は ((Q)-(P))+1 と同じ値を持ち、 -((P)-((Q)+1)) のように、式 P が配列オブジェクトの最後の要素の 1 つ後ろを指している場合、式 (Q)+1 がオブジェクトを指していなくても、値はゼロになります。配列オブジェクトの要素。...両方のポインターが同じ配列オブジェクトの要素、または配列オブジェクトの最後の要素の 1 つ後ろを指していない限り、動作は未定義です。
しかし、理論的には、上記の引用の中間部分と、クラス レイアウトおよびアライメントの保証を組み合わせると、次の (マイナーな) 調整が有効になる可能性があります。
union
これは、レイアウト、 との間の変換可能性などに関する他のさまざまな規定と組み合わせるchar *
ことで、元のコードも同様に有効になる可能性があります。(主な問題は、上記のポインター演算の定義に推移性がないことです。)
誰でも確かに知っていますか?N3242/expr.addは、ポインターが定義されるためには、ポインターが同じ「配列オブジェクト」に属している必要があることを明確にしているようですが、標準の他の保証が組み合わされた場合、とにかく定義が必要になる可能性があるという仮説が立てられます。この場合、論理的に一貫性を保つためです。(私はそれに賭けているわけではありませんが、少なくとも考えられると思います。)
EDIT : @MatthieuM は、このクラスは標準レイアウトではないため、基本サブオブジェクトと派生の最初のメンバーの間にパディングが含まれていないことが保証されない可能性があるという異議を唱えますalignof(T)
。それがどれほど正しいかはわかりませんが、次のさまざまな質問が開かれます。
継承が削除された場合、これは機能することが保証されますか?
&d.end - &d.begin >= sizeof(float) * 10
そうでなくても保証されますか&d.end - &d.begin == sizeof(float) * 10
?
最終編集@ArneMertz は、 N3242/expr.addを非常によく読むことを主張しています (はい、ドラフトを読んでいることは知っていますが、十分に近いです)。ただし、標準は、次の動作が未定義であることを実際に暗示していますか?行が削除されますか?(上記と同じクラス定義)
また、 if==
が十分に強くない場合はstd::less
、ポインターに対して全順序を形成するという事実を利用して、上記の条件を次のように変更するとどうなるでしょうか。
2 つの等しいポインターが同じ配列オブジェクトを指していると想定するコードは、標準の厳密な読み取りによれば本当に壊れているのでしょうか?
編集申し訳ありませんが、標準のレイアウトの問題を解消するために、もう1つの例を追加したいだけです: