[過去ﾛｸﾞ] C言語なら俺に聞け 162 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
415: (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/19(金)12:11 ID:Wkz3Ctqj0(2/5) AAS
void**とvoid*は相互に変換可能じゃないのか？
416: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)12:19 ID:vjpbBz8R0(3/9) AAS
変換が可能だということと同じ表現を持つことは別という話。
int* から void* への変換は変換に関するルールだが
int** から void** への変換によって int* を void* として読もうとするのは type punning の問題。
417(1): (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/19(金)12:20 ID:Wkz3Ctqj0(3/5) AAS
そうなると、
int** a = malloc(sizeof(int*) * 3);
は、保証無いことになるな
俺達はどうすればいいんだw
418: (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/19(金)12:25 ID:Wkz3Ctqj0(4/5) AAS
void** a = malloc(sizeof(void*) * 3);
の方が適切だったか
これで、a[0]の読み書きが保証されないのは困るよ
419: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)12:27 ID:vjpbBz8R0(4/9) AAS
>>417
繰り返すが変換の話と表現の話は異なる。
void* は全てのオブジェクトを指すポインタと相互に変は可能であることは保証され、
「malloc が返すポインタに限っては」いかなる型とも適合するように境界調整されていることが保証される。
420: (ﾜｯﾁｮｲ 313a-xGnM) 2024/01/19(金)12:34 ID:3hcnICbb0(1) AAS
【AI】Googleの医療面接特化AI「AMIE」は人間よりも正確な診断が可能＆患者への印象に優れるという研究結果 [すらいむ★]
2chｽﾚ:scienceplus
【AI】Google DeepMindが数学オリンピックレベルの幾何学問題を解けるAIを発表、人間の金メダリストに近い性能を発揮 [すらいむ★]
2chｽﾚ:scienceplus
【AI】大学入試共通テスト、3つのチャットAIに解かせてみたら？ GPT-4はバケモノだった [すらいむ★]
2chｽﾚ:scienceplus
【ナゾロジー】「株価の変動を粒子の振動として理解」量子力学で株式市場の法則を読む！ [すらいむ★]
2chｽﾚ:scienceplus
【AI】NTT、自分の分身AIを低コストで作る技術。自分の合成音声を簡単に作れる技術も [すらいむ★]
2chｽﾚ:scienceplus
省1
421(1): (ｽｯｯﾌﾟ Sd22-aNQv) 2024/01/19(金)12:39 ID:S8ovIeWid(1/3) AAS
何を言ってるんだお前は案件
ポインタの中身は指す対象によってアラインが変わるが
ポインタ自体のアラインは原則一種類しかない
422(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)12:51 ID:vjpbBz8R0(5/9) AAS
>>421
ポインタは型ごとに異なる表現・境界調整要求を持つ可能性がある。
適合する型へのポインタ同士の場合など同じ表現・境界調整要求を持つ条件が定められているが
最後に「これ以外の型へのポインタは、同じ表現又は同じ境界調整要求をもつ必要はない」と仕様に明記されてる。
具体的な部分は処理系定義なので全部が同じ表現であることをあてにしていい環境ならそうすることは否定しなけど、
常にあてにできるわけでもない。
423: (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/19(金)13:18 ID:Wkz3Ctqj0(5/5) AAS
そうは言っても、
void* p = 0;
と直接生成出来るわけで、void*は値としての意味もちゃんとある
それがvoid**にすると元に戻せる保証が無いのは仕様の不備だろw
424(1): (ｽｯｯﾌﾟ Sd22-aNQv) 2024/01/19(金)13:22 ID:S8ovIeWid(2/3) AAS
>>422
それは「ポインタが指す対象」についての記述で
ポインタ自体にはどんな適当な値を書き込むことも可能(そのポインタを使ってアクセスすると何が起こるかわからないというだけ)
ただポインタにNULLを書き込むだけの関数になんの危険もない
425(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)13:35 ID:vjpbBz8R0(6/9) AAS
>>424
> それは「ポインタが指す対象」についての記述で
この (>>410) 場合はポインタが指す対象に書き込もうとしている話だが。
426(1): (ｽｯｯﾌﾟ Sd22-aNQv) 2024/01/19(金)15:18 ID:S8ovIeWid(3/3) AAS
>>425
そのポインタは関数への引数であり
すでにvoid*を表すものだと型は決まってるではないか
それとは別に
インライン関数で書いた場合はその場で展開されるから
void* p = 0;と書いた場合と同様にコンパイラが適切な０を書き込んでくれるんじゃないの
つまり(void**)をつけると逆に危険
my_free(&x);
でよい
427(1): (ﾗｸｯﾍﾟﾍﾟ MM66-Fks1) 2024/01/19(金)16:04 ID:dJaf/W/GM(1) AAS
ポインタで0リテラルだけは特殊でNULLと同義だったのではなかったっけ
428: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)16:16 ID:vjpbBz8R0(7/9) AAS
>>426
> (void**)をつけると逆に危険
これは暗黙に型変換されることが保証される文脈ではないので付けなければコンパイルが通らないだけ。
(コンパイラによっては黙って通すことはあるのかもしれない。)
> インライン関数で書いた場合はその場で展開されるから
言語の意味論としてはインライン関数は
・ 同じ定義なら (翻訳単位を跨いだ場合でも) 複数回定義してもよい (定義が一回の場合と同じ挙動)
・ なるべく高速に呼び出して欲しいことを期待するヒントである (実現方法は規定しない)
ということになってる。
インライン関数がインライン関数ではない関数と異なる動作にはならない。
429(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)16:39 ID:vjpbBz8R0(8/9) AAS
>>427
せやで。
厳密に言えばリテラルだけじゃなくて「整数の 0 であるような定数 (定数式) をポインタに型変換したときは空ポインタ」というルール。
これも変換に関するルールであって表現に関するルールではないよね。
実際に空ポインタの内部表現が整数の 0 というわけではない環境は存在するが、
型が正しければ適切に変換される。
430(1): (ﾜｯﾁｮｲ 25bb-ggGG) 2024/01/19(金)16:53 ID:CCGmGKuQ0(1/2) AAS
>>429
それ規格書に書いてあんの？知らんかったわ
でも
if (!ptr)
みたいなポインタがゼロであることを期待するような式は処理系依存になるでしょ？
431(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/19(金)17:02 ID:vjpbBz8R0(9/9) AAS
>>430
いや、それがよく出来てて、ポインタをそういう形で条件に使うのは問題ない。
単項演算子 ! について「式!Eは，(0==E)と等価とする」というルールになっていて
等価演算子 (==) はポインタと空ポインタ定数を比較したときの結果を規定してる。
空ポインタ定数のほうをもう一方のオペランドの型に合う空ポインタに型変換するルール。
432: (ﾜｯﾁｮｲ 25bb-0zjl) 2024/01/19(金)17:32 ID:CCGmGKuQ0(2/2) AAS
>>431
規格書読んできたけど
6.3.2.3 値0をもつ整数定数式は空ポインタになる
6.5.3.1 式!Eは，(0==E)と等価
6.5.9 ==は空ポインタ定数をポインタの型へ型変換する
ってことか
なるほど、規格を解釈すれば!ptrは空ポインタと比較されることになるから問題ないのか
勉強になったわ
433(1): (ﾜｯﾁｮｲ 21d6-ggGG) 2024/01/19(金)18:55 ID:EWHtqHW90(1) AAS
NULLは処理系定義だしこの辺はややこしいよね
434(1): (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/20(土)00:57 ID:QcwVnceA0(1/6) AAS
void*の値は作成出来るけど、表現や境界調整要求は未定義とか、おかしいだろ
Cは現実に則した言語だと思ってたけど、妙な未定義だな
ちなみに、インタープリター型言語を作ったら、オブジェクトはみんなvoid*になる
void*の配列を作成したりとか普通に行われる
もはや規格とか無意味
実装がどうなってるかだけが重要だ
435: (ﾜｯﾁｮｲ c2c3-IYsG) 2024/01/20(土)10:29 ID:ZDCHWjSD0(1) AAS
>>433
全然ややこしくないでしょ
436: (ﾜｯﾁｮｲ 02ad-L3s4) 2024/01/20(土)10:30 ID:UfD1Ji0o0(1/3) AAS
> 実装がどうなってるかだけが重要だ
もちろんその通りだけど規格上未定義なわけだから実装がすべて統一されているとは限らないわけで
その実装における「限らない」が問題なわけでしょ
437(1): (ﾜｯﾁｮｲ cd59-lxZL) 2024/01/20(土)12:47 ID:Ttk7tIdd0(1) AAS
実際に使用する環境に合わせれば良いだけ
438(2): (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/20(土)13:33 ID:QcwVnceA0(2/6) AAS
各OS毎にABI(Application Binary Interface)が定義されてて、Cの規格で定義されてないところが明確に定義されてる
2つを合わせて現実のC言語なんだよな
だから、JIS X 3010だけを取り上げてどうこう言っても混乱させるだけ
439: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-/YAw) 2024/01/20(土)14:51 ID:k6CjZuQW0(1/2) AAS
>>434
実際には void* と int* (などのポインタ) が同じ表現なことは多いので
あまり問題 (type punning) にならないと考えるならそうかも。
ただ、表現が同じである環境ならかまわないのかというとそうでもない。
aliasing rules が絡んでくる。
言語仕様上で適合するとされる以外の読み書きをプログラマはやらない (やったら未定義だから) という仮定の元に最適化されることがある。
>>438
ABI はその名の通りインターフェイスを一貫させるための規定であって、
外部に公開しない (外部リンケージを持たない) 部分ではコンパイラは最適化するし、オブジェクトを除去することもある。
私は >>422 で「あてにしていい環境ならそうすることは否定しない」と述べたが、
省3
440: (ﾜｯﾁｮｲ 02ad-L3s4) 2024/01/20(土)14:57 ID:UfD1Ji0o0(2/3) AAS
だから、その環境が不明瞭なこういう場所で問題になるわけでしょ？
実際>>392では「処理系はANCI C準拠」としか言っていないわけだし
441: (ﾜｯﾁｮｲ 02ad-L3s4) 2024/01/20(土)14:57 ID:UfD1Ji0o0(3/3) AAS
おっと440は>>437-438アテネ
442: (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/20(土)15:58 ID:QcwVnceA0(3/6) AAS
未定義とは規格遊びには便利な言葉だなw
正解はconfigureスクリプトがやってるように、事前に環境を調査して前提にしていい事を明確にして最適な実装をする事だな
なので、言語仕様のみで判断を下す事は不正解と言える
その為にconfigureスクリプトがある
他の言語ではあまり必要ない
Rustとか最近の言語は言語仕様に不明瞭な点は残さないのがトレンドだろう
じゃなきゃそこが脆弱性を生んでしまう
443: (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/20(土)16:03 ID:QcwVnceA0(4/6) AAS
>>392のマクロは、副作用のある式を渡したりするとおかしな事が起きる
全くもって脆弱なものだ
そのままで良いのか？
マクロのままにしておくとか、そっちの方が脆弱性を生む事になる
ちゃんと関数化すべきだろ
その為にすべき事は何だ？
それを議論することが正解と言っている
444: (ﾜｯﾁｮｲ 2205-l2AN) 2024/01/20(土)16:33 ID:7OBiWfZx0(1/2) AAS
副作用のある式とは例えば?
445(2): (ﾜｯﾁｮｲ 82d4-niQV) 2024/01/20(土)19:48 ID:31IXtECu0(1) AAS
p++じゃない？
446(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 423e-B+Bj) 2024/01/20(土)19:54 ID:k6CjZuQW0(2/2) AAS
関数で書いたら問題を避けられるわけ？
447: (ﾜｯﾁｮｲ 0279-5stn) 2024/01/20(土)21:49 ID:VgpxxxtV0(1) AAS
C言語で今更議論することなんてないよ
気に入る要らないはモダン言語とかでやってなさい
448: (ﾜｯﾁｮｲ 450a-rpIY) 2024/01/20(土)22:17 ID:DXZ/M+lB0(1) AAS
使用済みのポインタ変数を変なやり方でクリアするとかクソどうでもいい
449: (ﾜｯﾁｮｲ 22ec-HXAs) 2024/01/20(土)22:21 ID:7OBiWfZx0(2/2) AAS
>>445
それは考えなくていいでしょ
450(1): (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/20(土)22:34 ID:QcwVnceA0(5/6) AAS
>>446
え？本気でいってんの？
関数で書けば副作用(例えば++p)は1回で済む
当然副作用がある式を書くのはアホだと思うが、少なくとも書いた通りには動く
451: (ﾜｯﾁｮｲ 463f-ggGG) 2024/01/20(土)22:44 ID:QcwVnceA0(6/6) AAS
例えば、(uint8_t)malloc(...) + sizeof(int)を返す関数もあり得る
これは前の方にデータを隠すテクニックだ
実はC++のコンパイラで普通に使われている
これを解放する時は、free(p -= sizeof(int))とやらない事もない
まぁ普通はp - sizeof(int)だろうから屁理屈だけどねw
452: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-3Dea) 2024/01/21(日)00:53 ID:4rk7TZPC0(1/2) AAS
>>450
解決したい問題はそれだけでいいのか。
それなら意図はわかる。
ただ現実に C の関数を多相化できないのは変えられない前提としてある。
異なる型で扱う必要があるんだから異なる関数を用意するしかないのはどうしようもなくない？
453: (ﾜｯﾁｮｲ e785-6dvo) 2024/01/21(日)11:37 ID:yYf7aVwb0(1) AAS
多相？
仮にポインタ変数のアドレス を引数で渡したい場合であってもvoid ** じゃなくvoid * を使って、
人間同士がドキュメントだろうが喫煙所だろうがで問題解決しろよってのが規画と整合する答えなんじゃないの
どうせキャストするんでしょうに
バカですか
454: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-G0Zh) 2024/01/21(日)12:09 ID:4rk7TZPC0(2/2) AAS
void* に変換したなら元の型にキャストしなおさないと保証された動作はほとんどない。
(逆に元の型に変換したときは変換前の値と一致することは保証される。)
元の型を知っているプログラマがキャストすることを期待できる qsort のような使い方なら問題にならないけど、
void* の形で受け取るだけでは関数が出来ることはほとんどない。
文字列を指すポインタに変換してバイト列として読み書きすることはアリなので
オブジェクトの内容はどうでもいいメモリブロック操作系の関数 (memmove など) だとかでも問題はないかな。
455: (ﾜﾝﾄﾝｷﾝ MM3f-NhvB) 2024/01/21(日)12:53 ID:+eMrRol8M(1) AAS
簡単な問題だったんだけど答えられる人ほとんどいないのか
相変わらず本題とは関係ない問答しだすアホらもいるし
456: (ﾜｯﾁｮｲ 7fc2-rEzG) 2024/01/21(日)13:01 ID:fu4eKftF0(1) AAS
答えられる人はいるだろうけど、宿題丸投げするやつにエサを与えたくなくて
敢えて書かない人もいるだろう。
457: (ﾜｯﾁｮｲ 5f79-i8QP) 2024/01/21(日)16:35 ID:ocg3B/5o0(1) AAS
ANCIとか頭悪そうな学校で相手したくなかった
458: (ﾜｯﾁｮｲ 5fad-zQB7) 2024/01/21(日)16:43 ID:WaBPg/nL0(1) AAS
誰も知らない新規格、か・・・
459: (ﾜｯﾁｮｲ e763-amFq) 2024/01/21(日)16:44 ID:sYjtPxaw0(1) AAS
宿題スレは別にあった様な気がする
460: (ﾜｯﾁｮｲ c7df-VcUz) 2024/01/21(日)20:09 ID:BpmEGVkv0(1) AAS
つ 2chｽﾚ:tech
461: (ﾜｯﾁｮｲ 7f2a-Hmn+) 2024/01/21(日)22:42 ID:fOwYJqZP0(1) AAS
UNCI はどうだろう。
462: (ﾜｯﾁｮｲ 7fab-JMeY) 2024/01/22(月)09:16 ID:wwjNYCJK0(1) AAS
>>445
free(p++);
p++=0; ←ここで文法エラーになるから
463: (ﾜｯﾁｮｲ 5fdb-0Ail) 2024/01/22(月)19:23 ID:sQG6cOu30(1) AAS
このマクロでそんな心配せんでええやろ
464: (ﾜｯﾁｮｲ 7f63-HLt9) 2024/01/22(月)20:21 ID:oQuCuzrM0(1) AAS
Cに引数の参照渡しってあったっけ?
ないとしたら>>392のMYFREE(p)をマクロではなく関数として書き
その中でp=0としても呼び出した側の変数は変えられないわけで
関数にすることで動作が変わってしまうことになるはずだけど
465: (ﾜｯﾁｮｲ 7f9f-EFyZ) 2024/01/23(火)13:25 ID:DCTvqhlA0(1) AAS
そんなこんなでp++マクロには問題が多いからC++が出来たってわけ
466: (ﾜｯﾁｮｲ e763-amFq) 2024/01/23(火)14:30 ID:FpD2d5od0(1/2) AAS
なんだそんな理由だったのか・・・
467(1): (ﾜｯﾁｮｲ df2d-EFyZ) 2024/01/23(火)14:41 ID:v+doC8dF0(1/2) AAS
mallocとcallocの引数の指定の仕方が違うのが気になる
これ別であることに理由あるの？
468: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-G0Zh) 2024/01/23(火)15:14 ID:MIeJSKFF0(1) AAS
>>467
言語仕様上は calloc が返すポインタ (によって表されるメモリ領域) は
malloc が返すものと同じようにあらゆる型に対して適切に境界調整されることになっているし、
ゼロクリアするという違いも「全てのビットがゼロ」という意味なので型の性質を考慮しない。
つまりふたつの引数として指定することによって得られる恩恵はない。
実装がまともなら calloc(a, b) としたときの a*b が size_t の大きさを超えてしまうようなときでも
ラップアラウンドして小さな領域を確保するのではなくエラーにしてくれることは期待できる
(間違いを検出しやすい) が、それを理由として引数ふたつにしているというわけではなさそう。
最初に言語仕様をまとめたときに主要な処理系がだいたい準拠ということになるようにしたはずなので
その頃の処理系でなんか理由はわからんがそうなってたって程度の話だと思う。 あまり意味ない。
469: (ﾜｯﾁｮｲ df2d-EFyZ) 2024/01/23(火)15:47 ID:v+doC8dF0(2/2) AAS
メリット無いなら統一してほしかったよ
470: (ﾜｯﾁｮｲ e763-amFq) 2024/01/23(火)16:35 ID:FpD2d5od0(2/2) AAS
好きな方を使いましょう
471: (ﾜｯﾁｮｲ 5f8c-/eig) 2024/01/24(水)09:58 ID:Xnuh8KFs0(1) AAS
統一したらゼロクリアするかしないかだけの違いにならん？
472(1): (ﾜｯﾁｮｲ e7bb-iTDz) 2024/01/24(水)16:48 ID:zBKRyD/E0(1) AAS
zmallocというマクロを定義すれば解決
473: (ﾜｯﾁｮｲ 5f7c-ytPG) 2024/01/25(木)18:11 ID:oxF0tkpI0(1) AAS
callocはmallocのゼロクリア版として *も* 使えるがそもそもの使い方が違う。
474: (ﾜｯﾁｮｲ bfac-8byG) 2024/01/25(木)20:28 ID:DorHRoYW0(1) AAS
ちなみに C には厳密にいうと価渡し(call by value)しかない
値としてアドレスを渡すので結果として参照渡し(call by reference)
ができることになる
475: (ﾜｯﾁｮｲ e763-amFq) 2024/01/25(木)20:55 ID:FFkj9zH80(1) AAS
参照って言うと色々誤解を受けるから
Cの場合はアドレス渡しで良いと思う
476: (ﾜｯﾁｮｲ dfbf-qZe7) 2024/01/25(木)21:27 ID:xC/Yy1/j0(1) AAS
ヘンな用語作るのやめて
ポインタで渡しても値渡しのまま
foo(int x) {int y = 0;x = y;}
bar(int *p) {int *q = 0;p = q;}
呼び出し元の変数に作用が無いのは同じ
両者は等しく値渡しのまま
baz(int *p) {int y = 0;*p = y;}
これについては値渡しされたものがポインタ型だったため
ポインタ型が持つデリファレンス機能によってポイント先に代入できただけ
*** 値として渡し ***て、デリファレンスして、代入しただけ
省12
477: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-3Dea) 2024/01/25(木)21:48 ID:d9W0b5Ok0(1) AAS
JIS の用語集やそのもとになった ISO 規格によれば call by address の定義はパラメタの場所を渡すこと。 ポインタの形であっても場所を渡しているには違いないからあてはまるし、勝手な創作用語というわけではない。
言語の理屈ではポインタもポインタという型の値だがそれの活用方法に名前が付いて悪いってこともない。
言語仕様の話をしているときに混ざってくると「んっ？」とは思うが。
478(1): (ﾜｯﾁｮｲ 5f10-iTDz) 2024/01/25(木)23:01 ID:NizTAU7c0(1) AAS
ポインタなのに値渡しとか言ってる奴まだいるのかw
そういうのはポインタ渡しで良いんだよ
アドレスを値渡し→ポインタ渡しでいいんだよ
479: (ｱｳｱｳｳｰ Sa4b-ZQy0) 2024/01/26(金)00:30 ID:/aFBudAaa(1) AAS
>>472
zalloc にしようぜ
480: (ﾜｯﾁｮｲ 5f7c-ytPG) 2024/01/26(金)00:35 ID:xuVVqQKb0(1) AAS
>>478
＞アドレスを値渡し→ポインタ渡しでいいんだよ
だよな。
481(1): (ｽﾌﾟﾌﾟ Sd7f-MQtI) 2024/01/26(金)08:38 ID:Nbs9AoGZd(1) AAS
Cの文法規則がいいかげんなんだよ
482: (ｽﾌﾟｯｯ Sdff-ytPG) 2024/01/26(金)09:12 ID:f6TAFOdQd(1) AAS
>>481
＞Cの文法規則がいいかげんなんだよ
だよな
483(1): (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)09:47 ID:5qejItpup(1) AAS
アドレスと言う値を渡してるのだからどちらも同じ事だろ
484: (ﾜｯﾁｮｲ e763-QAJh) 2024/01/26(金)10:37 ID:mR+OAnS80(1) AAS
いい加減なところが好かれる理由
485: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)10:46 ID:Tqv1qsfwp(1) AAS
アセンブラまんどくさいから作ったのがC
だから型がイイカゲンなのはアセンブラやってる人が対象だから
486: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-G0Zh) 2024/01/26(金)10:52 ID:6gE8lNl00(1/3) AAS
イイカゲンにしてるとコンパイラの最適化を有効にしたときに破綻するぞ
487: (ﾜｯﾁｮｲ 5f10-iTDz) 2024/01/26(金)12:43 ID:IWVVekFc0(1) AAS
>>483
構造体は値渡しとアドレスの値渡しがある
どっちも値渡しというと訳が分からなくなる
なので、構造体は値渡しとポインタ渡しが出来ると言えば便利だ
そうすれば、配列は値渡しが出来ないとも言うことが出来る
488: (ﾜｯﾁｮｲ c701-bKTd) 2024/01/26(金)13:17 ID:hEzJutz20(1) AAS
C++で参照が登場したので「アドレスの値渡し」とか言っている訳で
C++を知らんと意味不明だし違和感あるだろうな
489: (ﾜﾝﾄﾝｷﾝ MM4f-NhvB) 2024/01/26(金)14:03 ID:OnjHbhExM(1) AAS
C++がどうのとかは全然関係ないでしょ
490: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-3Dea) 2024/01/26(金)14:07 ID:6gE8lNl00(2/3) AAS
C++ とは関係ないと私も思う。
仮引数と実引数の関係は (型がポインタかどうかに関係なく) 値の代入であるということになっている。
繰り返すが言語仕様上の理屈では解釈の余地なく全ての引数は値呼びのメカニズムで規定されているよ。
C++ の参照と区別するための言い回しではなく仕様上の理屈通りに言えばそうなるってだけ。
491: (ﾜｯﾁｮｲ e7bb-iTDz) 2024/01/26(金)14:12 ID:u8n9O9U10(1) AAS
それで結局
&var
の値はポインタなの？アドレスなの？
どっちでもいいんだよね？
492: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 5f3e-3Dea) 2024/01/26(金)14:57 ID:6gE8lNl00(3/3) AAS
「アドレス」と「ポインタ」の使い分けはイマイチわからないんだよなー。どっちでもいいと思う。
単項演算子の & にはアドレス演算子という名前がついていてアドレスを返すとも書いてあるのでこれについてはアドレスと言っていいのは間違いない。
ポインタは型の種類のように使われてることもあるし、ポインタ型の値のことを指しているように見える箇所もある。
個人的感想としてはアドレスのほうが低レイヤ寄りの概念でポインタは型で意味付けしているような雰囲気を感じてるんだけどあまりはっきりしない。
493: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)16:28 ID:TUEfKZ6Qp(1) AAS
参照渡しと実体渡しかw
あれも、アドレス渡しとコピー渡しって言えばいいのにね
494: (ﾜｯﾁｮｲ 4710-zwhO) 2024/01/26(金)16:55 ID:VvnpRsjB0(1) AAS
アドレスは、数値が主体でそれが何を示しているかの説明の為の単語。
ポインタは変数の一つで *p や p->a 等の動作も含めての設計思想。
などと意味不明な(ry
495: (ﾜｯﾁｮｲ 5f10-iTDz) 2024/01/26(金)17:26 ID:CEoHa9Fg0(1/2) AAS
アドレスは値
ポインタは型だよ
正確にはintのポインタ型とか言うけど
496: (ﾜｯﾁｮｲ e763-amFq) 2024/01/26(金)17:35 ID:WoOISbdM0(1/2) AAS
ポインタはポインタ値を格納する場所
497: (ﾜｯﾁｮｲ 5f10-iTDz) 2024/01/26(金)17:36 ID:CEoHa9Fg0(2/2) AAS
場所と言うのは曖昧な表現だな
498(1): (ﾜﾝﾄﾝｷﾝ MM4f-NhvB) 2024/01/26(金)18:03 ID:Vqpo1a/ZM(1/2) AAS
アドレスは値で右辺値、ポインタは変数でオブジェクトで左辺値
こんな基本的なこと、頼むよ
499(1): (ﾜｯﾁｮｲ 7f19-rEzG) 2024/01/26(金)18:27 ID:GfgH9lD40(1) AAS
>>498 正しくない。ポインタ型の変数 int* p に対して p + 1 もポインタだけど、変数でも左辺値でもない。
500: (ﾜｯﾁｮｲ e763-amFq) 2024/01/26(金)18:29 ID:WoOISbdM0(2/2) AAS
ある時はメモリーのサラリーマン、ある時はレジスターの探偵
501: (ﾜｯﾁｮｲ e746-qZe7) 2024/01/26(金)19:46 ID:XBTJ48xK0(1/2) AAS
規格上はどうなってるか知らんが
ポインタでいいじゃん統一しろよ
変数へのポインタを取る時アドレスと言いたくなるんやろな
分からんでもないが使い分ける必要はないと思う
アドレスといいつつ結局ポインタでしかないやろ？
場所だけじゃなくて型のサイズも持ってるでしょ？
アドレスと聞くと番地だけってイメージだけど
ポインタっつうのはそれに加えてサイズも持ってるのがミソ
だから不必要にアドレスと言い直す必要はない
だって実際にポインタしか扱わないんだから
502: (ﾜｯﾁｮｲ 0791-RdP4) 2024/01/26(金)20:04 ID:Su75gAlu0(1) AAS
アドレスっていう言葉は規格には出てこないと予想してた。
規格にはポインタだけあればよくて、アドレスは実装の仕方のイメージがある。アドレスは多くの場合整数になるが、文字や文字列でもいいというような。
503: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)20:45 ID:wwCmUZ7Wp(1) AAS
アドレスってアセンブラ屋さんが言う奴？
504: (ﾜｯﾁｮｲ 5f36-zwhO) 2024/01/26(金)21:05 ID:pu3OCH3K0(1) AAS
バイナリーエディタやメモリエディタでも言うよな。
505: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)21:07 ID:coh7wFVpp(1) AAS
バイナリエディタのはアドレス違うよなぁ
メモリーエディタはアドレスだからいいけど
506: (ﾜﾝﾄﾝｷﾝ MM4f-NhvB) 2024/01/26(金)21:11 ID:Vqpo1a/ZM(2/2) AAS
>>499
p+1はアドレスだよ
507: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)22:21 ID:PDBFw7tbp(1) AAS
ポインターだろ
508: (ﾜｯﾁｮｲ e730-qZe7) 2024/01/26(金)22:21 ID:XBTJ48xK0(2/2) AAS
int a[4] = {0}, (*b)[4] = &a, *c = &a[0];
printf("%p %p\n", b, b + 1);
printf("%p %p\n", c, c + 1);
0x7ffc2026d710 0x7ffc2026d720
0x7ffc2026d710 0x7ffc2026d714
アドレスと捉えると同じ番地だけど
+1の結果が違う番地になるのは
ポインタが大きさを知っているから
これが単なる整数とは違うところ
509: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)22:22 ID:8+XG8rAlp(1) AAS
アドレスと言えるのは直接ハードウェアにアクセスするものだけだよな
510: (ﾜｯﾁｮｲ e7bb-iTDz) 2024/01/26(金)22:29 ID:kxxVAnT60(1/2) AAS
規格書の加減算のとこにはp + 1の結果が何になるか書いてある？
511: (ｻｻｸｯﾃﾛﾗ Sp7b-NMAD) 2024/01/26(金)22:36 ID:tuyRrB6Ip(1) AAS
p+1の結果は、pの型によって違うやろ
512(1): (ﾜｯﾁｮｲ e7bb-iTDz) 2024/01/26(金)22:48 ID:kxxVAnT60(2/2) AAS
規格ちょっと読んだけど加減算のところには結果がアドレスになるかポインタになるか書いてなくね？
513: (ﾜｯﾁｮｲ df20-NMAD) 2024/01/26(金)22:49 ID:4G76jppe0(1) AAS
>>512
アドレスはポインタのエイリアスだろ？
514(2): (ﾜｯﾁｮｲ 5f10-iTDz) 2024/01/27(土)00:39 ID:RxNi/RLS0(1) AAS
だから、アドレスは値で、ポインタは型なんだ
p + 1はpの型によって結果が決まる
intかintのポインタ型かで結果が変わる
上下前次1-新書関写板覧索設栞歴
あと 488 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.049s