タグ付けされた質問 「pointers」

メモリに格納されている別の値を「指す」データ型。ポインタ変数には、他のエンティティ(変数または関数または他のエンティティ)のメモリアドレスが含まれています。このタグは、参照ではなくポインタの使用を含む質問に使用する必要があります。ポインターを使用する最も一般的なプログラミング言語は、C、C ++、Go、およびアセンブリ言語です。特定の言語タグを使用します。他の有用なタグは、メソッド、関数、構造体などで、ポインタの使用を説明しています。

3
サイズ0の動的配列へのポインタの増分は未定義ですか?
AFAIK、ただし、サイズが0の静的メモリ配列を作成することはできませんが、動的配列を使用して作成できます。 int a[0]{}; // Compile-time error int* p = new int[0]; // Is well-defined 私が読んだpように、1つの最後の要素のように動作します。p指すアドレスを印刷できます。 if(p) cout << p << endl; イテレータ(最後の要素)ではできないので、そのポインタ(最後の要素)を逆参照できないことは確かですが、そのポインタをインクリメントするかどうかはわかりませんp。イテレータのような未定義の動作(UB)ですか? p++; // UB?

7
Cでポインター比較はどのように機能しますか?同じ配列を指さないポインターを比較しても大丈夫ですか?
K&R(Cプログラミング言語第2版)の第5章で以下を読みました。 まず、特定の状況下でポインタを比較できます。もしpとq同じ配列のメンバーへのポイント、その後のような関係==、!=、<、>=、などの作業を適切に。 これは、同じ配列を指すポインターのみを比較できることを意味しているようです。 しかし、私がこのコードを試したとき char t = 't'; char *pt = &t; char x = 'x'; char *px = &x; printf("%d\n", pt > px); 1 画面に出力されます。 まず第一に、私はので、私は、未定義またはいくつかのタイプやエラーになるだろうと思ったptし、px(少なくとも私の理解では)同じ配列を指していません。 またpt > px、両方のポインタがスタックに格納されている変数を指しているため、スタックtが大きくなり、メモリアドレスがx?どちらがpt > px本当ですか? mallocが導入されると、さらに混乱します。また、8.7章のK&Rには、次のように書かれています。 ただし、によって返されるさまざまなブロックへのポインターをsbrk有意義に比較できるという前提はまだ1つあります。これは、配列内でのみポインタ比較を許可する標準では保証されていません。したがって、このバージョンのmallocは、一般的なポインタ比較が意味のあるマシン間でのみ移植可能です。 ヒープでmallocされたスペースを指すポインターとスタック変数を指すポインターを比較しても問題はありませんでした。 たとえば、次のコードは正常に機能し1、印刷されました。 char t = 't'; char *pt = &t; char *px = malloc(10); strcpy(px, pt); …

4
void * function()は関数へのポインターですか、それともvoid *を返す関数ですか?
の意味がわかりませんvoid *function()。 それは関数へのポインタvoid*ですか、それとも関数が戻りますか?私は常にポインタを返す再帰関数としてデータ構造で使用しましたが、マルチスレッド(pthread)でコードを見たとき、同じ関数宣言があります。今、私はそれらの違いが何であるか混乱しています。

3
CにはC ++のstd :: lessと同等のものがありますか?
私は最近やっての未定義の動作に質問に答えるたp < qときCにpし、q異なるオブジェクト/配列へのポインタです。それは私に考えさせました:C ++は<この場合と同じ(未定義)動作を持っていますが、ポインターが比較できる場合std::lessと同じものを返すことが保証され<、できない場合は一貫した順序を返す標準ライブラリテンプレートも提供します。 Cは、(同じ型への)任意のポインタを安全に比較できるようにする同様の機能を持つものを提供していますか?C11標準を調べても何も見つかりませんでしたが、Cでの経験はC ++よりも桁違いに小さいため、簡単に何かを見落としていた可能性があります。

1
Cでのオブジェクトのオーバーラップのセマンティクスは何ですか?
次の構造体について考えてみましょう。 struct s { int a, b; }; 典型的には1、この構造体は、サイズ8と位置合わせ4を有するであろう。 2つのstruct sオブジェクトを作成し(より正確には、2つのオブジェクトを割り当てられたストレージに書き込みます)、2番目のオブジェクトが最初のオブジェクトと重なる場合はどうなりますか? char *storage = malloc(3 * sizeof(struct s)); struct s *o1 = (struct s *)storage; // offset 0 struct s *o2 = (struct s *)(storage + alignof(struct s)); // offset 4 // now, o2 points half way into o1 *o1 …

1
__func__ポインターの2つのconstexprインスタンスの違いはまだconstexprですか?
これは有効なC ++ですか? int main() { constexpr auto sz = __func__ - __func__; return sz; } GCCとMSVCは大丈夫だと思っていますが、Clangはそうではないと思っています:Compiler Explorer。 すべてのコンパイラは、これが問題ないことに同意しています:コンパイラエクスプローラー。 int main() { constexpr auto p = __func__; constexpr auto p2 = p; constexpr auto sz = p2 - p; return sz; } Clangはこれも好きではありませんが、他のものは問題ありません:Compiler Explorer int main() { constexpr auto p = …

1
不完全な型へのポインタは不完全なのでしょうか?
することができint (*)[]、不完全型で? C 2018 6.2.5 1は言う: 翻訳単位内のさまざまな時点で、オブジェクトタイプは不完全(そのタイプのオブジェクトのサイズを決定するのに十分な情報がない)または完全(十分な情報がある)の場合があります。 したがって、型のサイズがわかっていれば、型は完全であるように見えます。6.2.6.1 28は、特定のタイプのポインターは同じサイズ(ポインターvoidと文字、互換タイプへのポインター、構造体へのポインター、および共用体へのポインター)でなければならないことを指定していますが、他のタイプへのポインターは異なる場合があります。 すべてのポインター、またはの配列へのすべてのポインターがint同じサイズであるCの実装では、のサイズint (*)[]がわかっているため、完全なサイズになります。たとえば、大きな配列に異なるポインタを使用する実装では、サイズがわからないため、不完全です。 以下のようにMMが指摘し、構造これは、ポインタのサイズの実装が受け入れなければならないことを示唆している6.7.2.1 3に制約ごとに、最終的な可撓性のアレイメンバーを除き、不完全な型とメンバーを含んではならないstruct { int (*p)[]; }異なる有する実装ながらそのような配列のサイズは、制約違反を診断する必要があります。(これは、そのような宣言が厳密に準拠するCの一部ではないことを意味します。)

4
sizeofは、配列へのポインターのこの逆参照でどのように機能しますか?
ここに私は4つの整数のptr配列へのポインターがarrあります。ptr配列全体を指します。ptr[0]または*ptr配列の最初の要素を指すため、1を追加して配列ptr[0]の2番目の要素のアドレスを取得します。 sizeof(ptr[0])(ptr[0]配列の最初の要素へのポイントとして)最初の要素のみのサイズである4バイトではなく、配列全体のサイズが16バイトになる理由を理解できません。 int arr[4] = {0, 1, 2, 3}; int (*ptr)[4] = &arr; printf("%zd", sizeof(ptr[0])); //output is 16
9 c  arrays  pointers 

1
ポインターを使用して読み取り専用フィールドを変更できますか?しかし、なぜ?
私はC ++の出身で、C ++とC#のポインター間で非常に異なる動作を見つけます。 意外にも、このコードはコンパイルできます...そしてさらに...完全に動作します。 class C { private readonly int x = 0; unsafe public void Edit() { fixed (int* p = &x) { *p = x + 1; } Console.WriteLine($"Value: {x}"); } } これは私を非常に困惑させます、C ++でもconstオブジェクトを保護するメカニズムがあります(constC ++ではreadonlyC#ではなくC#とほぼ同じですconst)、ポインターを介してconst値を任意に変更する十分な理由がないためです。 さらに調べてみると、C#にはC ++の低レベルのconstポインターに相当するものはなく、次のようになります。 readonly int* p C#の場合。 その場合、pはポイントされたオブジェクトのみを読み取ることができ、それに書き込むことはできません。 また、constオブジェクトの場合、C#はアドレスを取得する試みを禁止しました。 C ++では、これを変更しようとするconstと、コンパイルエラーまたは未定義の動作になります。C#では、これを利用できる可能性があるかどうかわかりません。 だから私の質問は: この動作は本当に明確ですか?C#では知っていますが、C ++にはUBのような概念はありません …

1
@Hと@H [0]の違い
私が持っています var H: array of THandle; 次に、ループで複数のスレッドを作成し、Hの要素にスレッドハンドルを割り当てて、それらを待機します。@H [0]を2番目のパラメーターとして以下のWFMOに渡すと機能します。 WaitForMultipleObjects(Length(H), @H[0], True, INFINITE) <-- Works しかし、以下のように@Hを渡すと、WAIT_FAILEDで失敗します。GetLastErrorは「無効なハンドル」を返します。 WaitForMultipleObjects(Length(H), @H, True, INFINITE) <--- Fails. @Hが@H [0]と異なるのはなぜですか?

2
*(* uintptr)と**(** uintptr)の違いは何ですか
Go runtime/proc.goには、以下に示すコードがあります。 // funcPCは関数fのエントリPCを返します。 // fはfunc値であると想定しています。それ以外の場合の動作は未定義です。 //注意:プラグインを使用するプログラムでは、funcPC は同じ関数に対して// 異なる値を返す可能性があります(実際に は、アドレス空間に同じ関数の// 複数のコピーがあるため)。安全のため、 この関数の//結果を==式で使用しないでください。 //結果をコードの実行を開始するアドレスとして使用するのが安全です。 //go:nosplit func funcPC(f interface{}) uintptr { return **(**uintptr)(add(unsafe.Pointer(&f), sys.PtrSize)) } **(** uintptr)の代わりに*(* uintptr)を使用しないのはなぜですか。 だから私は理解するために以下のテストプログラムを書きます。 package main import ( "fmt" "unsafe" ) func main(){ fmt.Println() p := funcPC(test) fmt.Println(p) p1 := funcPC1(test) fmt.Println(p1) p2 := funcPC(test) fmt.Println(p2) } …
8 function  pointers  go 

2
多次元配列の空の文字列リテラルがnullポインターに減衰するのはなぜですか?
いくつかの文字列リテラルで初期化された多次元C文字列配列を定義したいと思います。ではC Iは、次の操作を行います: #include <stdio.h> const char *strArr[2][1] = { {"foo"}, {""}}; int main(void) { printf("%p\t%p\n", strArr[0][0], strArr[1][0]); return 0; } gcc -std=c18 -pedantic test.c結果をコンパイルして実行すると、次のようになります。 $ ./a.out 0x55d95410f004 0x55d95410f008 予想どおり、空の文字列リテラルはstrArr[1][0]有効なポインタに減衰します。 しかし、私は同じコードを試してみてくださいC ++: #include <cstdio> const char *strArr[2][1] = { {"foo"}, {""}}; int main(void) { printf("%p\t%p\n", strArr[0][0], strArr[1][0]); return 0; } g++ …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.