C言語なら俺に聞け 158

2021/12/25(土) 12:11:46.61

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 157
https://mevius.5ch.net/test/read.cgi/tech/1624846971/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/07/31(日) 19:20:45.67

今回「削除」になったのはいわゆるK&Rスタイルの関数定義くらいだな。
いずれ削除するということは以前から書かれてたし、
習慣的にも行儀が悪いという考え方が支配的だから
これで問題が起こるなら長い移行期間中に対応できてなかったほうが悪いと言ってよかろ。

2022/07/31(日) 19:35:38.56

削除って事は、古いソースのコンパイルはもはや出来ないと言うことなんでしょうか
いや、なに、クラシックカーに乗ってみたい位の好奇心ですけど

**アリ人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd9a-xqSD) · 2022/07/31(日) 19:46:09.16

歳をとるということ　〃
シワが増えるということ　〃

なのに
ぼくたち
私たちは　〃

なぜ、最新機種で進化の止まった古臭いコンパイラを使うのでしょうか
でしょうか

2022/07/31(日) 20:23:09.10

>>985
削除された機能を使っていればそういうことになるが、
そもそも C で書かれたプログラムなんてどこかしらで環境依存な部分があるもんだし、
よほど配慮されたものでない限り古いコードは素直には動かないのが普通だろう。

まあ C23 が出来たからと言って C89 (に対応したコンパイラ) が直ちに消滅するわけでもないし、
なんだかんだであと二十年くらいたっても C89 派がそれなりにはいそうな気がする。

2022/07/31(日) 20:35:31.51

K&R CこそCの面白さの塊なんだけどな
GCCが「カバにダンスを踊らせるのはあまり面白くない」なんて言ってた人もいるように
歳月とともに雁字搦めになっていく流れは酷くつまらない

**デフォルトの名無しさん** (US 0H7d-p9PZ) · 2022/07/31(日) 20:47:12.68

>>988
でもね、C のコンパイラは C で記述してほしかったですね
確かにカバの調教は難しいのかもしれませんが
というか、gcc をコンパイルするためだけの c で書かれた c++ コンパイラって需要ありますかね？

2022/07/31(日) 20:51:31.04

>>988
無理すんなよ

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd9a-xqSD) · 2022/07/31(日) 20:59:27.98

そろ次スレ

2022/07/31(日) 21:03:23.63

ラージモデルでFarポインタ使いまくったプログラム合ったけど、
今は流石に見るのも嫌だと思う
何言ってるか分からないと思うが、俺も分からない

2022/07/31(日) 21:17:26.94

>>992
むしろnearポインタの方が面倒だと思うが...

2022/08/01(月) 08:38:31.30

あり人間とかキチガイ、こっちでも頓珍漢なこと書いてるのか

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 25e6-p9PZ) · 2022/08/01(月) 19:47:44.58

>>992
ラージモデルの far ポインタでしょう？別に far とか書かなくても普通にポインタを書けば far ポインタになったはず
であれば、あとは 64kb の壁を意識してむやみにポインタのインクリメントをせずに上手に部分にわければなんとかなったでしょう

far ポインタでの経験はいろんな場所で活かせる貴重な体験だと思いますよ
私は試食版 LSI-C のスモールモデルで陽に far を指定して far ポインタをバリバリつかっていましたよ
スモールモデルだからコード領域はせまいけれども（near コールしか使えない）、far と書けばデータは 640KB までフルに使えましたし

2022/08/01(月) 20:05:11.09

インテルのクソ設計でみんな迷惑してたってだけの話
K&R Cの楽しさとは全く何の関係もない
68kと86系は異次元の世界だった

2022/08/01(月) 20:55:56.73

>>995
テキトー書く前に8086 メモリーモデルとか near far huge とかでググってから出直してこい

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 25e6-p9PZ) · 2022/08/02(火) 07:34:13.90

>>997
私の認識であってますよ
ラージモデルのデフォルトポインタ（データ・コードとも）は far ですし、スモールモデルはどちらも　near
しかしスモールモデルでも far ポインタは　far と陽に宣言すれば使えるんですよ…

2022/08/02(火) 11:58:06.82

Windows16ビットのCでは16ビットハンドルを架空の構造体へのnearポインタとして実装してたな(#define STRICTした場合)
例えばデバイスコンテキストハンドルをビットマップハンドルに代入しようとするとtype mismatchエラーになってすぐわかる
STRICTでないと単なる本来の16ビット整数として扱われ混同しても通ってしまう
win32ではnearがないので普通の32ビットポインタになってしまいメモリがちょっともったいない

2022/08/04(木) 18:41:17.13

>>92push(保存)してpop(書き戻し)してるから結局pushしたときのデータになる
popとpushの間のややこしいとこはシカトな

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 222日 6時間 29分 31秒