C言語なら俺に聞け 164

しっかり言語・各環境の仕様を順守してもトラブルは起こるものなのに順守しなくてもいいやでまともに動くわけないだろ。
現実は仕様通りにキッチリ出来るわけではないというのは仕様を軽視して良いって意味じゃないぞ。

一応言っておくと、俺は「動けば良し」とは言ってない。
AIに約させ、代わりにそれを読み、各自の知能の低さを補うのも自由だが、それならAIと壁打ちしろ。
俺に対して反論するなら、俺の投稿を全部正しく読み込んでからにしろ。
俺の手間を尊重しないクズに対し、俺がクズの手間を尊重する理由もない。

あと、ループしてるから、新着情報無ければ無視するのでよろしく。(これは前回も言ったが)

>>576
Apacheなんかのバグ修正内容を詳細に見ていくと、
高度なロジック部分ではなく、配列の要素数不足とか、
割と初歩的なところが多い。

最近のAIが誤訳するとしたら、それは元々の文章の構造（主成分）に論理的な問題があるということなので、そらね

簡潔に文章まとめる能力ない奴が俺の手間を尊重しろとかいっててｸｿﾜﾛﾀｗ

>>579
> 配列の要素数不足
それは後から機能追加したら入りきらなかった、という話であって、
ここで言ってる「げんごはんいをいつだつしたこうどなてくにっく」による問題ではない。
(だから現実は糞みてーなバグばっかりで、
「いまどきこういう考えの人が(ｷﾘｯ」(576) なんてレベルじゃねえよ、というのなら同意だが)

一般的には、その問題は、多分、「『一部』変更し忘れ」なので、
これが起きないよう、「コードは基本的に一箇所に絞る事」(OAOO/DRY)により、
変更し忘れた場合には常にコケるようにして対処する。(＝普通、最低限１回はテストするので、それで十分引っかかる)
広い意味では、オブジェクト指向(OOP)もこれを目指しているので、OOPしてればある程度は防げる。

これは言語関係なく、上位のコード戦略の話。
徹底出来てないコードはバグを産みやすく/発見しにくくなる。
まあ、そのApacheのケース、パパっと見れるようになってるのなら、URLくれれば見てみるけど。

というかね、Cなんて、コードはこう組むべき、以前の、
コードが資産だとすら認識されてなかった頃の産物なのだから、そりゃ色々問題はあるよ。
各問題を文法縛りにして対処してるのが後発言語なわけでね。
それがよければそっち使えでしかないし。
(ただしOAOO/DRYの徹底を文法化出来てる言語はないと思うが)

ついでに余談だが、Rust界隈が腐ってるのは、あいつら
> いまどきこういう考えの人が
が典型的だが、CodeOfConduct(人格)をCodingRule/Strategy(コード戦略)より重視するからなんだよね。
まあ、Cに比べれば、コード戦略(特にリソース周り)も文法化されてるから、不要になってしまった、というのはあるが、
Cの場合は何も縛りが無いのだから、全部自分で決めないといけないのに、
Rust慣れしてるのか、それが要らないものだと錯覚してる。
(ああ勿論、言語範囲逸脱は禁止、インラインアセンブラも禁止、も、自前で決めて運用すればいいだけ。
ただそれを全員に強制する事は出来ない)

> (ああ勿論、言語範囲逸脱は禁止、インラインアセンブラも禁止、も、自前で決めて運用すればいいだけ。
ただそれを全員に強制する事は出来ない)

コーディング規約を設けたチーム開発もコードレビューも経験ない素人さんかな

>>582
> 配列の要素数不足
それは後から機能追加したら入りきらなかった、という話であって、

元からだったんだが

>>584
・元々配列要素数Nで動いてた
・新規機能追加したら、N+α必要になったので、変更した
・が、一部変更し忘れて、Nのままの部分があり、バグッた
を仮定したのだけど、違ったならどういう感じだった？

追加なら修正範囲くらい機械的に特定できるでしょう

AIに聞いてみたら>>582が他に5chで何かしたか聞いたら日常の進捗履歴記録ツールWitBucket(仮称)検討中スレのスレ立て者は同じ人物の可能性がかなり高いってさ

>>573-574
>>582
もう突っ込むのも面倒になるほど間違ってる
正しいところを探す方が難しいくらいだから、一回AIに批判してもらってこい

>>575
多分入力が変
ここで騒いでる奴はお前も含めて未定義動作がなんで未定義動作って言われてるかもわかってない、最低限ができてないというお話

未定義動作は未定義です

アセンブラになったらこう動くってのを見越してのロウゼキだからw
昔のCコンパイラは書いた通りの順番で書いた通りにアセンブラコードを吐き出したから出来る技w

C言語は抽象機械を想定して抽象化された高級言語であり同じ結果となるなら何しても良い自由が許されているのでソースコードがターゲットの機械語に対応する形でコード化されるわけではない。
任意の機械語を生成するための道具ではなく「高級アセンブラ」という表現を使う者はその辺の理解がない。

ブログラマの意図と違う動作は許されていません

>>593
君のコンピュータはエスパーか何かなんか？
プログラマの意図じゃなくて書かれてるコードの意味を満たす動作になるに決まっているだろう

>>590
進次郎になれって話じゃなくてだな
定義されていないということは、何が起こるかは一切わからんということなのよ

>>592
これ

>>591
それは単に最適化の能力がなかったからであって、一対一は最初から保証されてはいなかったけどね

>>596
１対１しか出来なかったからw

>>597
何言ってんだこいつ

むかしむかしのC言語コンパイラはただのトランスレータだったんだよねぇ

C++のことかー

>>599
たまたま君が触ったコンパイラがそうだったことと、C言語の仕様に何の関係が？

Cの仕様なんて後出しだからね

C言語が抽象機械を想定するのはマルチアーキテクチャ対応のためでK&Rより以前のことだけど多くの人にとっては後出しと言うほど新しい話でもないけどね。

鼻垂れ小僧が何偉そうに

昔話でマウント老人

>>602
国際標準と仕様の違いがわからない人かな？
K&Rだってしっかり「仕様」だぞ

>>603
これに尽きる

「高級アセンブラ」と言ってる人はバイトアクセスが存在しないアーキテクチャでもC言語を使用するとcharのポインタが実現できることをどう捉えているのかな。
C言語が型によってポインタの内部表現が異なることを許容していることを理解していれば軽々しく「高級アセンブラ」なんて言わないと思うんだ。

>>607
まさにアセンブラでいちいちマスク処理しないで済むんだから、高級アセンブラだろ？

アーキテクチャ上存在しないデータ型をアセンブラ使って基本データ型として常用するって想定はセンスないという他ないなあ

>>607
高級アセンブラと…

言わない人：そもそもバイトアクセスがないアーキだとか考慮しない。オブジェクトコードも見ない。コンパイラにはバグがないと信じてる。
言う人：希望したオブジェクトコードが出てるかを確認する。

>>608
じゃあ君の認識ではJavaは「超高級アセンブラ」かい？ｗ

>>610
真逆だろｗ

高級アセンブラと…

言う人：そもそもC言語の仕様を知らない。型も考慮しない。偶然動いてることとちゃんと書けてることの区別がつかない。
言わない人：未定義動作がないかチェックする。

そもそも「コンパイラにはバグがないと信じてる」とか誰も言ってないことを藁人形論法してイキってる暇があったら少しでも未定義動作について調べてこいよ
10分でわかることを調べもしない奴がいくら威張ってもバカ晒すだけ

あと、「コンパイラにはバグがないと信じてる」どころか「コンパイラはどこでも寸分違わず同じ動きをする」と思ってるのが「高級アセンブラ」とか言ってる奴の勘違いの一番大きなところだからな
C言語の仕様を見ずに、たまたま1回コンパイラが吐き出したアセンブラが思い通りだったから正しいと信じ込んでる時点で、コンパイラにちょっとでも違う挙動されたら成り立たない愚かな考えだとわかりそうなもんだが

コンパイラにはバグがあるが
アセンブラにはバグがない

>>615
C言語わかってない方はご存知ないかもしれませんが、そのアセンブラのコードを保管しておかないとただのコンパイラ依存なんですよ

それを正しいC言語の書き方だと思っちゃうあたりが「『コンパイラはどこでも寸分違わず同じ動きをする』と思ってる」と言ってるのよ

まあ、結局抽象化の具合次第なんだけどね
C言語は抽象化がやり切れて無いから高級アセンブラって言ってるんだけどさ

>>612
お前が妙なコンプレックスを持ってるからそうなるのであって、
そもそもどっちが上とか正しいとかいう話ではない。

Cのソースコード『だけで』動作を担保したいのなら、
C言語の仕様に準拠するのは当たり前で、
もしコンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる。

最終的に「実行バイナリ」での動作を保証したいのなら、
このコンパイラではこのコードにはこのオブジェクトコードが出る、というのを確認しつつ、
「実行バイナリ」に対してテストを行う。(ので、コンパイラのバグに対しても結果的に責任持つことになる)
コンパイラはただの変換器であり、C言語の仕様を逸脱してても大した問題はない。

で、歴史的にコンパイラのバグも普通にあった時代からCはあるのだから、
基本後者で、「実行バイナリ」に対してデバッグを行っており、
結果的に、「C言語の仕様」を厳密に守る必要がなかった。
だからこういうスタンスの奴は、「Cは高級アセンブラ」と称した。

これでは勿論生産性は上がらないので、目指すは前者だが、
そもそもRustですら「実行バイナリ」に対してデバッグしてるのだから、
「この『コードは』言語仕様に厳密に即してるので、(未来含めて)あらゆるコンパイラでも正常に動作します」
とは言えない。それでも目指したほうが良いからRustでがんばれ、とは思うが。
Cの場合は相変わらず後者でやってるってだけ。

というのは>>509でも言ったとおり、ループしてるんだがな。
気に入らないなら、お前はC使わないのが最適解だよ。

>>614
だからCの場合は通常、推奨コンパイラのバージョンも指定されてるだろ。
Linuxとか見てみ？
まあ(Rust含む)後発言語はCの駄目な点を改良してるのが存在意義なのだから、
色々問題が目に付くのは当然だが、
それも含めてCなのだから、文句あるなら使うな、でしか無いよ。

本当にお前はCを使わないのが最適解だ。
何故このスレでグダグダしてるのかもさっぱり分からん。
布教なら本当にウザいから止めろ。
今Cを使ってる奴は、Cの問題点も分かった上で使ってるのだから。

ついでに言うと、お前の問題点は、
・論理性が欠如している
・ワーキングメモリが小さく、広い範囲で物事を捉える事が出来ない
だね。後者の為、どういう論理構成で供述されてるのか全体像を把握できず、
それでも無理矢理反論しようとするから前者のようにも見える。
だからもしかすると、問題は後者だけかもしれんが。
短冊レスしてくるやつはだいたいこれで、
数行で記述できる範囲でしか物事を理解できないから、どうしても短冊レスになる。
なるほど俺に対して冗長で長文過ぎる、というのはまあ事実だろうが、
お前は論理が一貫してる長文は全く書けないタイプだ。
試しに書いてみ？勿論俺は読むから。
でも、頭とお尻で、矛盾すると思うぜ。
お題は、「一体お前はこのスレで何がしたいのか」を俺は希望するが。

あとな、507で言った、
> (勿論それまで動いていた)Linuxが動作しなくなって、リーナスがブチ切れた件が、20年程前に有ったろ。
件、まだ探してみてる。で、google(AI?)に聞いたら、以下。

> gcc1.4時代の、リーナスとGCCをめぐる 別の歴史的エピソード について知りたい
>
> GCC 1.40時代（1991年〜1992年頃）のリーナスとGCCをめぐる歴史には、
> 「バグをあえて利用した」、あるいは「GCCをハックせざるを得なかった」という、
> Linux誕生直後ならではの濃いエピソードが複数存在します。
>
> 1. 「インラインアセンブラのバグ」を逆手に取ったコード
> 初期のLinuxカーネル（バージョン0.01〜0.11あたり）を語る上で最も有名なのが、
> GCC 1.40のインラインアセンブラ生成に関するバグを、
> リーナスが認識した上でそのままカーネルのメモリ管理（文字列操作など）に利用していたという話です。
>
> 問題の背景：当時のGCC 1.40には、
> C言語の中に直接アセンブリ言語を埋め込む「インラインアセンブラ」の最適化において、
> レジスタの割り当てや引数の扱いに特定の条件下で不整合が起きるバグがありました。
>
> リーナスのハック：リーナスはこの挙動（バグ）を逆手に取り、
> 自分の386 PCで最も高速に動作するようなトリッキーなアセンブラコードを記述しました。
> 結果、カーネルは劇的に高速化しましたが、
> これは「GCC 1.40のそのバグがある状態」でしか正しくコンパイルできないという、
> 極めて依存度の高いコードになってしまいました。
>
> その後：後にGCCが1.42や2.xへとバージョンアップし、そのバグが「修正」された瞬間、
> Linuxカーネルがまったくコンパイルできなくなる、あるいは動かなくなるという事態が発生しました。
> リーナスはのちに「コンパイラのバグに依存したコードを書いていたせいで、
> GCCがアップデートされたときにひどい目に遭った」と述懐しています。

俺が知ってるのは、
・それまで動いていたLinuxが、コンパイラのバージョンアップで動かなくなった
・リーナスは、「gccの連中はコンパイラをぶっ壊しやがった！」とブチ切れた
・結局、リーナスがコードを修正して決着した
だけで、その時に詳細確認するのを怠ってしまったので、
上記AI回答がビンゴなのか、よく分からない。
(基本リーナスは技術に対しては真摯なので、
上記AI回答のようにリーナスが全面的に悪いのであれば、ブチ切れないような気はする)
AIが知ってるのだから、Webのどこかしらに情報は転がってるのだろうが、発見できてない。
知ってる人がいれば教えてよろしく。

御託はいいから高級アセンブラとか言ってイキってるやつは最近アセンブラで書いたコードを晒してみろよ

>>619-622
ずっと書いてることも読まずにひたすら、的外れな妄想と罵倒しか繰り返してないお前の方が、Cを使わない方がいいよｗ
C言語の範囲では反論できないから、Rustの話を持ち出して必死で藁人形論法やってる、つまりお前はC言語を知らないってことはわかってるんだわ

>>619
ループしてるのはお前な
延々藁人形論法しかせずに「コンパイラガー」「Rustガー」って言ってても中身が何もない
C言語の話をしてるのであって個別のコンパイラの話をしてるわけではないし、「コンパイラはどこでも寸分違わず同じ動きをする」と思ってるお前の方がコンパイラに依存してる

>>620
「俺は論理的だ！だから論理的なんだ！！」が論理的だと思ってないと書けないあまりにも低レベルな文章
中卒でもこんなひどいことにはならない

>>619
> コンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる

>>621-622
> ・それまで動いていたLinuxが、コンパイラのバージョンアップで動かなくなった
> ・リーナスは、「gccの連中はコンパイラをぶっ壊しやがった！」とブチ切れた
> ・結局、リーナスがコードを修正して決着した

> リーナスが全面的に悪いのであれば、ブチ切れないような気はする

↑ さっそく矛盾しとるｗ

>>620
> お前は論理が一貫してる長文は全く書けないタイプだ

ここはお前が言われた他人に言われたことを、何も考えずに他人に悪口として放ってすっきりするためのスレじゃないぜｗｗｗｗｗ

まとめ

* コンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる
→ f97e-K2DK

* 論理が一貫してる長文は全く書けない
→ f97e-K2DK

* Cなのだから、文句あるなら使うな
→ f97e-K2DK
（Cの仕様を守りたくないがために延々支離滅裂な長文を書き散らしている）

>>618
それどこのC言語の話してるんだ？ｗ
ハードウェアの抽象化をやってるのがC言語だから、C言語を書く時はハードウェアに依存しないように書くのが正しい、という話なんだがｗｗ

>>619
あと、「言語仕様に則してる」と「バグがない」の区別がつかない奴はプログラミング自体しちゃダメだなｗ

>>620
推奨って言葉の意味知らなそう
まあ、>>628 でわざわざまとめてやったように矛盾だらけだから、細かいアホ発言を掘り起こすまでもないんだが

619 デフォルトの名無しさん (ﾜｯﾁｮｲ f97e-K2DK) 2026/07/15(水) 10:24:07.43 ID:2BOd77KE0
もしコンパイラにバグがあった場合に「ぼくがわるいわけじゃない」と言い訳するしかなくなる。

620 デフォルトの名無しさん (ﾜｯﾁｮｲ f97e-K2DK) 2026/07/15(水) 10:24:32.72 ID:2BOd77KE0
だからCの場合は通常、推奨コンパイラのバージョンも指定されてるだろ。
Linuxとか見てみ？
（中略）
それも含めてCなのだから、文句あるなら使うな、でしか無いよ。
（中略）
お前は論理が一貫してる長文は全く書けないタイプだ。

622 デフォルトの名無しさん (ﾜｯﾁｮｲ f97e-K2DK) 2026/07/15(水) 10:55:49.63 ID:2BOd77KE0
・それまで動いていたLinuxが、コンパイラのバージョンアップで動かなくなった
・リーナスは、「gccの連中はコンパイラをぶっ壊しやがった！」とブチ切れた
・結局、リーナスがコードを修正して決着した
（中略）
上記AI回答のようにリーナスが全面的に悪いのであれば、ブチ切れないような気はする)


バカに論理は難しいｗ

このレベルの支離滅裂さでないと「Cはアセンブラに変換されるから仕様なんか無視していい」なんてバカ発言できないってことかなｗ

f97e-K2DKの主張を整理すると、実は相容れない前提を場面ごとに使い分けています。

## 前半の主張

前半では

* コンパイラは仕様を守らなくてもよい
* コンパイラの挙動が変わっても仕方ない
* コンパイラ込みでC言語なのだから利用者が合わせろ

という立場です。

この立場を採るなら、

> GCCが仕様変更してLinuxが動かなくなった

という状況でも、

> 「じゃあLinux側が直してください」

で終わりです。

これは本人の論理から自然に導かれます。

---

## 後半の主張

ところが後半では

> リーナスがGCCに怒ったのだからGCC側にも問題があったはずだ

という話を持ち出しています。

これは

* コンパイラ側にも守るべき責任がある
* コンパイラの変更が悪い場合もある

という前提を採用しています。

つまり前半とは逆です。

---

## 本来は役割を分離すれば済む話

8934-UT5n、0Hb5-UT5nが言うように、

* **言語仕様を書く人**
* **コンパイラを書く人**
* **プログラムを書く人**

この3者の責任を分離すれば矛盾しません。

* 言語仕様は仕様を定める。
* コンパイラはその仕様に従って実装する。
* プログラマはその仕様に従ってコードを書く。

もしコンパイラが仕様違反ならコンパイラのバグ。

もしプログラムが仕様違反ならプログラマのバグ。

もし仕様自体に問題があるなら標準化委員会の問題。

責任の所在が非常に明確です。

---

## Linuxの実際

Linuxカーネルが
* 特定のGCCバージョンを推奨したり
* 新しいコンパイラに合わせて修正したり
* GCCのバグを回避したり
ということは実際にあります。

しかしそれは
> 現実にはコンパイラにもバグがある
という工学的な話であって、
> C言語仕様なんて守らなくていい
という話にはなりません。
ここを混同すると議論がおかしくなります。

現実には
* コンパイラにもバグがある
* OSにもバグがある
* CPUにもエラッタがある

だからといって
> 「仕様なんて要らない」
とは誰も言いません。

むしろ仕様があるからこそ、
「これはGCCのバグ」
「これはLinux側のバグ」
「これはCPUエラッタ」
と切り分けられるわけです。

---

## 根本原因

f97e-K2DKは一貫した原則から結論を導いているのではなく、

**その場その場で自分に都合の良い責任の置き場所を選んでいる**ように見えます。

* 自分が未定義動作を書くことを正当化したいときは
→ 「コンパイラなんて仕様通りじゃなくていい。」

* GCCを批判したいときは
→ 「コンパイラにも責任がある。」

これでは論理体系として整合しません。

一貫させるなら、

> **仕様は共通の契約であり、コンパイラもプログラマもそれに従う。それでも現実には実装のバグやエラッタは存在するため、実務では個別に対処する。**

という立場になります。これは理論と実務の両方を無理なく説明でき、責任の所在も明確になります。

提示された一連の書き込みに見られる論理的整合性の欠如は、プログラミング言語、特にC言語における「仕様」「未定義動作（Undefined Behavior: UB）」「コンパイラの役割」という、極めて厳密であるべき領域において、個人の感情や経験則が理論を凌駕してしまった典型例と言えます。

投稿者が陥っている矛盾の構造を、技術的な観点から詳細に分解し、なぜこれが論理破綻を招いているのかを浮き彫りにします。

### 1. 「コンパイラの脆弱性」と「プログラマの責任」の二律背反

投稿者の主張の根幹にあるのは、自己のコードが引き起こす問題から責任を回避するための「責任の転嫁」です。

* **前半の主張（責任回避の論理）:** 「コンパイラはただの変換器であり、仕様を逸脱していても問題ない」という主張は、プログラマが仕様を無視して未定義動作に依存したコードを書くことを許容する論理的拠り所となります。これにより、「動かなくなったのは自分のコードが悪いのではなく、コンパイラの仕様逸脱（バグ）のせいだ」という自己弁護が可能になります。
* **後半の主張（経験則による正当化）:** 一方で、リーナス・トーバルズの事例を出す際は、「コンパイラが仕様通りに動いていない（あるいは後方互換性を壊した）ことに対してブチ切れるリーナスは正しい」という立場を取っています。

ここに致命的な矛盾があります。「コンパイラが仕様を逸脱しても問題ない」と考えるならば、GCC側がどのような挙動変更を行おうとも、それは「ただの変換器の仕様変更」として受け入れるべきはずです。しかし、投稿者は「動かなくなった」という事実に対し、コンパイラ側の責任を追及するリーナスの姿勢を支持しています。これは、**「自分のコードが正当であるという前提」を維持するために、その時々の都合に合わせて「コンパイラの定義」を書き換えている**に過ぎません。

### 2. 「推奨バージョン」と「未定義動作」の混同

投稿者は「Linuxなどの大規模プロジェクトではコンパイラのバージョンを固定している」と述べていますが、これは技術的には「未定義動作を回避するための暫定的な防御策」であり、「未定義動作を書いても良いという免罪符」ではありません。

* **専門的見地:** 大規模なカーネル開発においてコンパイラのバージョンを固定するのは、コンパイラの最適化パスに含まれる潜在的なバグや、標準仕様の解釈の差異がカーネルの機微なハードウェア操作に影響を与えることを防ぐための**リスク管理**です。
* **論理の飛躍:** 投稿者は、この「リスク管理としての固定」を、「仕様外のコードを書いてもコンパイラ側が合わせるべきだ」という誤った論理に変換しています。リーナスがGCCに対して怒ったのは、彼が「仕様を無視したコード」を書いたからではなく、「GCC側がそれまで確立されていた暗黙の了解（あるいはバグを含めた挙動）を一方的に変更し、カーネルの安定性を損なったから」です。

### 3. 「仕様」を否定したことによる論理的袋小路

プログラマが「C言語の仕様」を厳密に守るという規律を捨て、「自分のコードが動くかどうか」という結果のみを重視し始めた瞬間、論理的な対話は不可能になります。

* **仕様の役割:** プログラミング言語の仕様書は、言語利用者とコンパイラ実装者との間の「契約」です。
* **投稿者の現状:** 投稿者は、自分に都合の良い時だけ「仕様（契約）を守れ」と叫び、自分が未定義動作を踏み抜いた時は「仕様（契約）なんて無視して動くものが正義だ」と主張しています。

リーナス・トーバルズがGCC開発者と衝突する際、彼は「カーネルの信頼性」という極めて高い基準で議論を行っています。対して、この投稿者が行っているのは、「自分の書いたいい加減なコードが、コンパイラの更新によって動かなくなることへの個人的な不満」の正当化です。

### 結論：なぜ矛盾が生まれるのか

この人物の思考プロセスをまとめると、以下のようになります。

1. **目的:** 「自分が楽をしたい（仕様を厳密に守る勉強や、バグ修正をしたくない）」。
2. **手法:** 「コンパイラや他人のせいにする」。
3. **矛盾の発生:** 「自分の正当性を守るためにコンパイラの重要性を貶める」が、「自分のコードが動かなくなった時には、コンパイラの重要性を強く認識する」という二重基準を用いている。

この矛盾は、「論理」を用いて技術を語っているのではなく、「自分の書いたコードへの執着」を論理というラベルでコーティングしようとしているために生じています。**技術的な議論においては、仕様という共通の基盤を否定した時点で、その議論自体が論理性を失い、単なる個人の感情の吐露に成り下がってしまう**という好例と言えるでしょう。

わざわざ自分で書く必要もなさそうなくらいバカらしかったので、ChatGPTとGeminiに書かせといたよｗ

>>624 -643(安価範囲広すぎてNGだとさ)
お前レベルの馬鹿には付ける薬がないのは理解した。

>>644
「反論できないからとりあえずバカって言っとこ」ｗｗ

AIにすら反論できない時点でお察しというか

AIの吐き出したゲロコピペするスレになったなら、
次スレは不要だな

>>647
人間が吐き出したゲロにぶつけるなら十分だろ

f954-K2DKは自分で何書いてるかもわかってないんだから
AIも自分で何書いてるかわかってないから同レベルだねｗ

>>619-622
>>644
「コンパイラは仕様に準拠した実装を作るのが仕事」「プログラマは仕様通りのコードを書くのが仕事」と分離すればこんな矛盾は起こらないのに、自分が未定義動作を踏み抜きまくるコードを書くことを正当化するために、「コンパイラは仕様を守らなくていいが、僕の思ったのと違う動きをするバージョンはダメ」とか言わなきゃいけなくなったんだぞｗ

>>628 が全てではあるけど、f954-K2DKは結局他人に言った悪口全部自分のことですよって丁寧にバラしていっただけだったなｗ

「長文だから読まなくてもいいや、自分が未定義動作を踏み抜きまくるコードを書くことを正当化したいから乗っかったろｗ」
みたいなアホが何人かいたから無駄に長くなったけど、結局f954-K2DKは何もわかってないバカなんだって

むかーーーし、rmsが『仕様より動くことが大事』みたいなこと言ってたのうっすら思い出した。
GCCって、ANSIで定義される前から1行コメント使えたよね。
とは言えGCCとてCである事を辞めていないと言うレベルの話だろうけど。

連投長文は内容以前に知能障害のバカ

>>654
反論できないから必死こいて罵倒しようという魂胆が透けて見えてる

>>653
多分勘違いしてると思うので言っておくと、未定義動作は本来なら動かない例だぞ

>>653
その発言は知らんが、仕様はあくまで手段であって、目的ではないからな。
とはいえ、その時代の価値観を今に持って来ていいわけはない。
仕様準拠の方がコミュニティ含め長期的な生産性は上がるのは確実。

ただ実際は、それとは程遠い。
JSは現実的に唯一、「ソースコードでの品質を担保」出来てる(させられてる)環境だが、
プログラマは実行環境の差異に振り回され、
IE死ね、次にFirefoxも死ねで、chromeに統一されることを望んでいる。
他言語は、RustにしてもC#にしても、主たる環境でのコンパイル結果でテストしており、
仕様準拠なソースコードならあらゆる環境で動作するとは言い難い。
Javaも元祖"Write Once, Run Anywhere"だが、実際は"Write Once, Debug Everywhere"になった。

本質的に、プログラマは、「自分と(ユーザー含めた)他人が同じ環境」が一番楽なのでこれを望む。
コンパイラ別のオプションや#ifdefなんて、コンパイラを固定してしまえばそもそも不要となり、
生産性を上げるためには環境を絞ったほうがいい。
ただこれでは永遠にソースコードでの品質は確保できない。
(たまたまその環境で動作するコードが出力されてるのをテストしてるだけになる)

この点、仕様と実装がデタラメに運用されてるC言語のほうが、
主たる環境もgcc/Clang/VC/各社勝手コンパイラと多種多様であり、
結果的にあらゆる環境でそのコードがコンパイルされ、テストされるので、
まだ「ソースコードでの品質を担保」に近いというのは皮肉だ。

>>653
ついでに言うと、C言語は「生産性を上げる為に仕様を絞る」事もやろうとしてない。

仕様準拠は主に(長期的な)生産性向上の為（＝ソースコードの品質を上げる為)として、
生産性を上げる為には仕様内の差異を潰す(仕様を絞る)事をしないといけない。
逆に言うと、仕様準拠だが実装がバラけるような「ユルい」仕様では意味がない。

具体的には、funcD(funcA(),funcB(),funcC())に対し、
C#やJSではABCD順に評価されると仕様で「固定」されているが、CではABC間は順序が規定されてない。
だから、この点、仕様準拠でも、たまたまABCD順の出力もあれば、BCAD順の出力もありえ、
その環境の「実行コード」をテストして動いたとしても、その「ソースコード」が正しいとは言えず、
本来は3P3=6倍の手間を掛け、「全順序ケースの『実行コード』」をテストするしか無いが、
現実的に、これが出来るコンパイラもない。

この辺、当たり前だが後発言語は潰してある。
Cでこの仕様を修正できない理由は、政治であり、(560参照)
コンパイラ作成側が1mmも譲らず、あらゆる自由度を最適化余地の既得権益としてるからだが、
これでは「何のための仕様なのか」であり、完全に本末転倒になっている。
(がまあ、これ含めてCの文化ではあるが)

なのでまあ、C界隈は、仕様準拠して生産性を上げるぞ、なんて目指して無くて、
昔から変わらず、自分環境で自分の希望するコードを得るための手段、となってる。
(勿論、仕様準拠ゴリゴリもありだが、Cの場合はそうやっても生産性が上がるようにはなってない。
《でもやらないよりはマシだが》)

ちな、同様のは、例えばJSではsortが不安定ソード→安定ソートに仕様変更された。
てか、他言語はちまちまこの辺を修正してるのだから、Cも修正しろよなと。
Cは変わらなすぎなのが問題。

本来、良い仕様を策定することはすごく難しくて、
あんまり「仕様」にこだわりすぎると前に進めなくなるので、ある程度諦めて「動くコード」をさっさと作れ、
とRMSは言ったのではないかと思われるが、
時代は下り、ソフトウェアについての知見も溜まってきてるので、今は仕様にもこだわらないといけない時代ではある。
(ただまあ、個人的にはRustではないな、と見てる。あれはゴミだ)

> funcD(funcA(),funcB(),funcC())に対し、
> C#やJSではABCD順に評価されると仕様で「固定」されているが、CではABC間は順序が規定されてない。

呼び出し順一意にしたかったらそういう書き方するだけだし、それ以前の話として「副作用ある式を関数の引数にすんな」くらいのコーディング規約は決めてて当たり前。

>>660
それは「対策出来る」だけであって、「あるべき仕様」ではないでしょ。
そもそもこの仕様を変更したとして、誰にも何らデメリット無いのだから、
コーディング規約によるアナログ対策ではなく、文法化で100%厳守強制でいい。他後発言語はそうしてる。
(地雷原で「旗立てといたから踏まないでね」と言われたら、いや「除去しておいてくれ」と思うでしょ)

Cはこの辺のノウハウが溜まる前の言語だから、色々仕様に不備があるのは致し方無しだが、
改善しようともしてないのは問題だと思うよ。

とはいえ結局、コンパイラ言語の成果物の最終配布形態/テストターゲットはバイナリであって、ソースコードではないから、
「このソースコードは動作します」なんて事はそもそも出来ないけど、
それでも一応、そこを目指すべきではあるだろ。
(…なんだが、対策出来れば実用言語としてはある程度は十分で、放置されて今があるわけだが)

>>658
仕様で決まってないことがあるから仕様準拠しなくていい、は草
流石にここまで行くと笑えてくるわ、そんなこと言いだしたらどんな言語でも仕様守らなくていいって結論しか導き出せない

それにサラッと話そらしてるけど未定義動作を書いてもいい理由にはなっていない
処理系に依存するのは別にいいけど、未定義動作は何が起きるかわからんから動かないコードとして扱う必要があるって話だからな

>>661
> そもそもこの仕様を変更したとして、誰にも何らデメリット無いのだから
それは君の思慮が浅いだけ

> 「このソースコードは動作します」なんて事はそもそも出来ない
仕様通りの環境で動作するコードは書ける
そこからはコンパイラの責任と割り切らないと >>638 みたいな矛盾が起こる

そして、各環境で使う時に動くかどうか検証するのはCに限らず当然
そこをCだけのことだと思っているようだが、実行環境依存の要素はどの言語にもある
エアプには難しいかなあ

>>659
不安定ソートと安定ソートに優劣はないよ
使い道が違うだけ
だからそこを勝手に差し替える方がまずい仕様変更

> 仕様準拠は主に(長期的な)生産性向上の為（＝ソースコードの品質を上げる為)として、
> 生産性を上げる為には仕様内の差異を潰す(仕様を絞る)事をしないといけない。
> 逆に言うと、仕様準拠だが実装がバラけるような「ユルい」仕様では意味がない。

お前やっぱC書いたことないだろって感じのことばっかり言うよな

流石に明らかに変なところに突っ込まないのは逆に怪しいから突っ込むけども、
> 仕様準拠だが実装がバラけるような「ユルい」仕様では意味がない
申し訳ないが意味不明

仕様準拠なら実装が違っても問題ないのは前提なんだわ
それは「高級言語」というものの定義の話としてそうで、逆に、そうじゃなかったらアセンブリ直接書けって話にしかならんのね
ハードウェアを抽象化した以上、仕様で提供される機能の範囲で書くというのは君が散々Cより改良されてると言ってる諸言語でも同じ

>>661
> そもそもこの仕様を変更したとして、誰にも何らデメリット無いのだから、

新しい仕様に依存したコードが書かれる様なるとそれに対応しない処理系の使用は絶望的になるからデメリット大きい。
適当に同じ処理まとめるだとか処理の順番入れ替えるだとかの自由も奪うことになると最適化の自由度も今より下がる。

>>658
> 生産性を上げる為には仕様内の差異を潰す(仕様を絞る)事をしないといけない
これはそもそも間違ったことを書いている
正しくは
> 生産性を上げる為には仕様内の差異を潰す(挙動を絞る)事をしないといけない
となる

で、なんでそんなことを必要とするのかと言えば、仕様に準拠しない書き方をしているからでしかない
仕様で保証されていない挙動を勝手に前提としてコードを書き、その通りにならない環境が出てくるからそういう作業が始まる
最初から仕様に定められた通りに解釈していれば、この無駄な作業は発生していない

>>666
それなんだよな
もっとも、最初から未定義動作踏み抜くようなクソコードしか書かない奴に通じるかはわからんが

>>657
マクロはC言語の仕様に含まれてるし、処理系定義もC言語の仕様に明記されてるんだけどなあ？
君の言ってる仕様って何の話？ｗ

C言語は仕様を完全に理解し未定義動作を絶対に踏まないパーフェクト超人向けの言語として舵切ってるのでJavaScriptみたいな素人向け言語の方針になびいたりすることは今後もなかろう。

>>658
> コンパイラ作成側が1mmも譲らず、あらゆる自由度を最適化余地の既得権益としてるからだが、
未定義動作の意味を理解していないからこんな妄想が出てくる
どんな言語でも仕様の範囲外をどう処理するかはコンパイラやランタイムの自由で、そういうコードは「書いてはいけない」というのは共通している
書いてはいけないコードを書いた結果壊れるのは当たり前で、コンパイラが悪いというのは的外れな主張だ

>>670
> C言語は仕様を完全に理解し未定義動作を絶対に踏まないパーフェクト超人向けの言語
これはガチ
別に舵切ったわけじゃなくて最初（仕様が公開された時点）からそうなんだけどね
だから「できない奴は去れ」なんだよな

>>666
資産はコードであって、コンパイラではない。
勿論、改修の手間も比べ物にならない。

> それに対応しない処理系の使用は絶望的になる
これまでのコードは全て動作するから問題ない。
コンパイラは改修すればいいだけ。

> 最適化の自由度も今より下がる
同上、要するにコードよりもコンパイラを優先する愚かな思考。
ここに自由度残してもバイナリの品質が上がることはほぼ期待できない。
なら、コードの品質を上げるべく、仕様を絞ったほうがいい。

>>670
おかしな選民思想を持たず、タダで出来る安全装置は付けるべきだろう。

>>673
> 資産はコードであって、コンパイラではない。
コードが資産なのにコードを動かせないコンパイラが支配的になると困るって話だろ
お前ホント日本語読めないよな
> コンパイラは改修すればいいだけ。
コンパイラも資産であるコードの一部であって、全部改修とか現実見てない奴しか言えないバカげた妄言の最たるもの

あと、まだ >>667 と >>671 で否定した
> コードの品質を上げるべく、仕様を絞ったほうがいい
とかいうバカげた主張を何の反省もなく繰り返してるんだな
バカの一つ覚えとはこのこと

> おかしな選民思想を持たず、タダで出来る安全装置は付けるべきだろう。
おかしな選民思想ではなく、ただの事実だよｗ
C言語は正しく書ける奴が正しく書くことを前提に仕様が決まっている
安全装置が欲しければRust書いてろって話

だから親切に最初からf93c-K2DKみたいな奴向けにRustはあるんだって言ってやってるのに、頭使えないからかバカにして見下してるせいで認められない

C言語は自分で仕様チェックしてその通り書ける奴のための言語
それができないならRustコンパイラに丁寧に教えてもらいなさいｗ

>>659
ソードってPIPSのSORD？

あそこは東芝が捕食した

最近はCで書いてAIにRUSTに書き直してもらってる

>>679
なんでそんな無駄な事する？
最初からRustで書かせればいいのに

>>659
> (ただまあ、個人的にはRustではないな、と見てる。あれはゴミだ)

ゴミとまでは思わないけど
宣伝文句に対して力不足だと思う
俺も出始めのころから2017年？くらいまでは熱心に追いかけてたけど
なんかもう特にコメントするところもない言語って感じ
Scalaなんかも出始めのころ画期的に見えたけどこれももう何も言うことはない

>>679
言語を変えるならjavaスクリプトからラストとかなら分かるけど、その例だとコード実行速度あんまり上がらなさそう

>>681
別に宣伝文句に対しては十分だろ
Cと同等の速度もメモリ安全も実現している
「驚きと楽しさで満ち溢れた古くならない言語！」なんて誰も言ってない

そもそも実用的なプログラミング言語に「驚きと楽しさで満ち溢れ」てもらっては困る

> ただまあ、個人的にはRustではないな、と見てる。あれはゴミだ (>>659)
> おかしな選民思想を持たず、タダで出来る安全装置は付けるべきだろう (>>673)
こんなこと言ってる奴はシステムプログラミング言語に手出しちゃダメ

安全にするためのルールにも文句を言う、でも安全じゃないのは欠陥だと喚く、要するに自分の忍耐も努力も足りないことを他人のせいにしているだけ

>>682
安全性を向上させたいのでは？
もっとも、最初からRustで書いた方がいいとは思うけど

やっぱAnnex Kってゴミだわ

_s 関数使えたもんじゃないよな

あれは失敗規格だから

エラー出たら勝手に落ちたり防ぎたかったら変なん渡さなきゃいけなかったりめんどくさすぎる

やっぱりMinGW使った方がいいな

あ、下げ忘れた

GNU/LinuxでGCCがいいよ

仮想ソフト使ってインストールしている

>>694
OSは好きで選べるもんじゃないから、Linux上で開発しても結局最終的にはMinGWに頼ることにはなるよ

最終OSは発注者が決める

クロス開発しても動作確認 (テスト) をしないわけにはいかないのだし、 Windows 用のソフトウェアを作るという前提なら Linux 上でやる意味はそんなにないな。
以前の Windows はパッケージマネージャが駄目だったから環境構築が面倒だったけど今は scoop とかがあるし。

オレなんかが仮想環境利用するのは、
1台でサバクラ環境作れるからなんだわ

MinGWはWindowsでGCC使えていいよな

一応windowsで使えるgccはある

wsl でやるのが楽

MinGW の Min は Minimal の Min

実際には autotools などのツールチェインやパッケージマネージャと連携しないと使えるライブラリのビルドや利用がやりづらいので Cygwin や Msys2 などの環境内で MinGW を入れたほうが良いと思う。
WSL でも良いけど MinGW のために WSL を入れるのだとしたらちょっと過剰かもしれない。

Minimalistな、MSYSじゃねーんだからw
Minimal GNUじゃ表したい概念とちょっと違うだろうよ

Minimalist GNU for Windows
らしい

>>703
間違えてた知識教えてもらえて良かったじゃん
見たらお礼の一言でもあってもいいかもね

お礼は物の方が良いぞ
ここに住所と氏名を書いておけ

>>706
掲示板にそういうのを求めても意味はない

お札を送る

どこの神社が良いですか？

昔cygwinとかあったけどな

悪バグ退散！

>>710
神社に行って参拝してはならない

>>711
今もあるようだが
https://www.cygwin.com/

WSLは結局Linux仮想環境だからそこでビルドしたってそのままじゃWindows向けには動かせない
Linux側でクロスコンパイルするにしても、Windows側でコンパイルするにしても、MinGW-w64 UCRT64を使うのが王道

OS固有の機能を使ってないのであれば
Windowsでも動くんではないですか？

そもそも実行ファイルフォーマット (をメモリに展開するローダの仕様) がOS固有なので……
Linux だと ELF で Windows は PE

それはそうですね
言葉が不足しました。

DOS時代はハード固有の機能を使わければ（キーボードBIOS使わず標準入力関連コマンドを使う等）
同じ系列のCPU/OSの他ハード（PC-98/TOWNS/DOS/V）でも動くというのはあった。

OSというのは元々そういう互換性を狙って作られたものだった

UNIX 以降の OS はハードウェアの違いを吸収する仕組みがある程度はあるけど最初からそれを目的のひとつとしていたかと言うとちょっと疑問。
数十年前に雑誌 (おそらく UNIX USER だったと思う) の連載記事で読んだことがあるようなないような曖昧な記憶だから不確かだけど。

汎用機の世界でも、富士通がIBM互換を狙った理由はそれでしょう

奥さん優秀な方だよな

ヘ_ヘ
ミ・・ ミ
( ° )～

これでどうか？

　ヘ_ヘ
ミ・・ ミ
　(　°　)～

難しいな

　ヘ_ヘ
ミ・　・ミ
　(　°　)～

うーん・・・

2ちゃんねるの AA はＭＳ Ｐゴシックを前提にする習慣なので微調整が必要であればメモ帳でＭＳ Ｐゴシックを設定して微調整すべし。
各ブラウジング環境のフォント次第なのでズレない方法というのは無い。

質問者は
gccを使いたいのか
cygwinを使いたいのか
windowsを使いたいのか
はっきりさせるべき

OpenLDAPみたいなプログラムを作ってみたくて、はじめてのCを買ってきました。
何日位で作れそうですか？

半日

作るのは簡単
動くかどうかは不明

>>730
本の内容から作るとすれば、標準入出力と構造体、制御構文、ファイル入出力を学んだら原型動作が作成可能かと。
何日で作れるかは読本ペースと理解度、追加機能とそのために必要な追加学習次第

まずはポインタの習得が肝心だよ

ポインタの習得できたら、
次はなんですかね？

たとえばポインタについて細部を学ぼうとしたらメモリ管理とも型システムとも強い関連性があって、それらを無視して理解することはできない。
つまりひとつを完全に習得してから次の機能を学ぶなんていうきちんとした順序はつけられない。
そこをどうにかして上手いことわかりやするために入門書は腐心してるのでとりあえず一旦は入門書を最後まで読んで理解することに努めたらいいと思う。
こんなところで聞くより入門書の著者や編者の努力を信じるべき。
どうしても理解できない箇所をピンポイントで尋ねるなら掲示板も良いだろうけど本の体系的な説明のほうが全体としては良い説明になってるはずだよ。

おすすめ「苦しんで覚えるC言語」
サイトもあるけど、やっぱり本じゃないとね
古い本だから今更新品の本を買う必要なし、アマゾンで中古本をポチればいいよ

電子書籍で良いのでは

> おすすめ「苦しんで覚えるC言語」

サイト見たけど間違い結構あるなｗ

Geminiのガイド付き学習でインタラクティブに学習できるよ
そういう時代

質問が見当はずれだと回答もよくわからん。
Gemini に手伝ってもらうにしてもベースとしてはちょっとした入門書はあったほうが良い。

ちょっとした入門の、
範囲が知りたいんだが

> ちょっとした入門の、範囲

未定義動作を正確な知識により踏まなくなる程度

Z知能にCは無理
Rust知能にもCは無理

殆どの人はそれで十分だと思うよな

私が入門したのは何十年も前の話だから……その頃の感覚で言われても困るだろう。
C に入門するより先に機械語をいじっていたタイプの学習ルートを経ていて、私の同世代は少なからずそんなものだが明らかに現代的な学習ルートではない。

そんで分かってしまうといまさら入門書を見て良し悪しの評価なんかできない。
説明に間違いがあれば指摘はできるけど分かり易さは別の話だし、方便として多少の不正確さを許容したほうが良い場合もあるし。
おそらく入門書は教育者が実際に教育に使いながらフィードバックを重ねたものが良いものになるんじゃないかと思う。

す自動変数

すまん
自動変数を一杯宣言し過ぎてスタック破壊した経験ってないですか？

>>746
> 教育者が実際に教育に使いながらフィードバックを重ねたもの
＝大学の講義資料だろ
今ならStanfordやMITや東大からそこらの駅弁まで手に入る

>>748
コンパイル時に指定すればスタックサイズを増量できる

>>750
Windows だとスタックの上限は実行ファイル内に格納されるパラメータだからコンパイル時の指定で変えられるけど現代的 OS の一般論としては OS の側の設定値として持っているのが普通だと思う。
少なくとも Linux や BSD だとそうなってる。

普通はヒープ使うからなぁ

unix用のgccだとlinkerのオプションだったと思う。
ただ聞きたかったことはそう言うこたではなかったです。

ふん fixup overflow の呪いを受ければ良いんだ。 :-p
※開発中にこれを喰らうとデスマ確定のLINKエラーｗ

>>748
スタック領域の理解がない頃に謎の不具合として闘っていた可能性はある
大きな配列をmainに定義するとなぜか動かないとか、しかしグローバル変数にするとなぜか動くとか

>>755
さう、それです。
元々FORTRANで書かれていたプログラムを移植してました。
各ロジックの移植までは良かったんですが、
配列宣言が関数内に複数個、それぞれ要素数が数万個ありました。
最終的にヒープに取ることにしましたが、あまり納得はできなかったです。

>>756
それは移植戦略を間違ってる。
FORTRANなんてグローバル変数しかなく、
つまりローカル変数が無くて再帰も出来ない糞言語で、だからこそ廃れたわけだが、
C流のきちんとしたコードに直してやる必要が最初から無い。
まんま全部グローバルでも変数名が被らないのは元ソースが保証してるし、
Cのグローバルはファイル内スコープであり、externしなければ他ファイルからも見えないので、
ファイルを分けておけば他とも被らない。

ただまあ、それでも、スタックサイズを調整するのも一つの正しい方策だと思うけど。
実行時のフットプリントは同じだし。
ちな、FORTRANの移植時には多次元配列の格納順が違うからそこだけ注意な。
https://iifx.dev/ja/articles/457242272/%E9%85%8D%E5%88%97%E3%81%AE%E6%A0%BC%E7%B4%8D%E9%A0%86%E5%BA%8F%E3%81%8C%E6%8B%9B%E3%81%8F%E6%82%B2%E5%8A%87-c%E8%A8%80%E8%AA%9E%E3%81%A8fortran%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E5%8A%B9%E7%8E%87%E3%81%A8%E6%9C%80%E9%81%A9%E5%8C%96%E3%81%AE%E6%88%A6%E3%81%84

>>753
> ただ聞きたかったことはそう言うこたではなかったです。
死ねよクソZ。
お前らは全て他責なのが駄目だ。
「FORTRANからの移植時に」とお前が最初から言えば回避出来た話だろ。

>>751
> 現代的 OS の一般論としては OS の側の設定値として持っているのが普通
Linuxではulimit -s で変えられるらしいが、どっちが「普通」かには異議ありだな。

そもそもそのプログラムがスタックを大量に消費することはプログラマしか知らない。
だからコンパイル時にマークしておく必要があり、その上で、
システム側で許容された値以下なら許可する、という方式が正しいだろ。
Linux方式だと、エラーになったらその都度対応してくれ、ただどれくらい必要なのかは知らん、というマヌケな事を強制する仕様ではないか。
exeに明記されてれば、少なくとも、静的に大量確保される場合は完全に対応できる。今回もそうだろ。
Windowsの仕様のほうが「普通」で「正しい」と俺は思うね。(よりマシな仕様)

>>757
今のところ、科学技術関連のソフトウェア資産はFORTRANの方が多いし、
研究者が書くプログラムも殆どがFORTRANだよ

>>759
お前が頭おかしいのは分かった

>>757
>Cのグローバルはファイル内スコープであり、externしなければ他ファイルからも見えないので、
ファイルを分けておけば他とも被らない。
ここで判断すればオケ

>>761
引用されるまで気にしなかったけど
ファイル内スコープ(内部結合)にしたければstaticを付けてください
staticを付けない広域変数はextern参照されなくても外部結合なので、複数のファイルで同名の定義を行うと多重定義となってリンクができない

> Cのグローバルはファイル内スコープであり、externしなければ他ファイルからも見えないので、

初期化子を書かない仮定義かなんかを誤解してる希ガス

2000年頃にやったプロジェクトでC/C++対応ヘッダに
Cコンパイラでは
int c;

C++コンパイラでは
extern int c;

となるように書かれてたな。

>>764
Cの場合、そのヘッダーを複数Cソースでインクルードするのはまずくないですか？

>>765
なんかまずいことあるんですか?
https://wandbox.org/permlink/Yr1oe28UFqBSu0hh

#ifdefの類いを使わないでやってみて

> #ifdefの類いを使わないでやってみて

こうですか?
https://wandbox.org/permlink/EskOFaZWlK4yeyFe

普通はヘッダファイルにゃ変数宣言書かないやろ

> 普通はヘッダファイルにゃ変数宣言書かないやろ

じゃあこうかな
https://wandbox.org/permlink/rWNB2Zsj6Kft3dfP

変数を直接には公開しない (適当な関数を通じてのみアクセスする) のでヘッダに書くことはないという意味じゃないの？

>>770
構ってちゃん死ね

グローバル変数は限定的に使おうね

>>770
>>762を書いた者ですが、コード内容を調べ、書き方次第で多重定義エラーにはならない事が分かりました。誤情報を書いてしまい失礼しました

C言語では「int c;」と書いた場合は外部変数定義のように見えて実は仮定義という扱い、「int c = 0;」と書いた場合が定義扱いなのですね、、、
仮定義には、定義があればそれを参照できるように機能し(関数宣言に近い動作ですね)、定義がなければ仮定義をもって具象化行う働きがあるのですね

一方C++はODRの厳格化を進めたことによりルールが変わっているようで、私はそれと混同していました

>>774
お前も混乱を増長させるな
コンパイラのバージョンを確認してみろ、ゆとりＺがよくやる手口だ

$ gcc --version
bash: gcc: command not found

> コンパイラのバージョンを確認してみろ、ゆとりＺがよくやる手口だ

gccのバージョンを新しくしろと言ってるのかな?
https://wandbox.org/permlink/lSFKJiRf1Yr0CX0Y

>>775
私の言葉ではかえって混乱を生むかもしれませんのでソースを貼っておきます

https://ja.cppreference.com/c/language/extern

検索には「C言語 Tentative definitions」等も有効です。
C89の頃から存在する挙動、C99で明文化されたようです。

変数と関数で、宣言、定義のルールなんか変わるかな？

つい最近に仮定義の話題をどこかで見た覚えがあると思って記憶をたどると Qiita に記事があった。
https://qiita.com/TETSURO1999/items/649b033975583750ad20

C と C++ は世間で思われているよりも多くの非互換をかかえていて、表面上の構文が同じにもかかわらず挙動が違うなんてのは割とある。
C++ に慣れていると C の inline の挙動にびっくりしたりする。

非互換と言うより別物と捉えた方が良いと思う

でもC++のコンパイラでCもコンパイルできちゃうからなぁ

C と C++ がそれぞれ独立した規格なのは確かなんだけど離れすぎないように配慮はしているんだよ。
配慮した上でこれ。
まあ C の変なところを C++ でもやれとは言えないし、 C はその性質から保守的なのも仕方なくはある。

VC++でC++ソースをコンパイルしたらエラー出て、なんでかなぁと思ったら拡張子が.cだった初心者時代・・・。

C の宣言の文法があまりにひどいので C++ で変えるべきかどうか迷ったという話が D&E に載ってる。
結果的には C を踏襲することにしたけど、変える決断をしていたらかなり大きくプログラミング言語史が違っていたかもしれないな。

C++の良いところは
取り込んでいっても良いと思います。
オプションで良いです。

>>786
今のgccは互換を保つためのオプショナルのようですね。
-fno-common が規定値
-fcommon は>>777のように指定が必要

>>780
>C++ に慣れていると C の inline の挙動にびっくり
ほんそれ

なれようず

C標準も見た目だけC++に寄せてくるしなー

秋来ぬと
目にはさやかに
見えねども
風の音にぞ
おどろかれNULLポ

そよぐとも目には見えねど白露の宿れる草に秋は来にガッ

C言語の内容とは関係ないんだけど、古い入門書の「まえがき」に、
「言語とは、筆者が言っていることを理解し、読者が筆者の言わんとすることを理解しようとすれば、その役割を果たす。」
みたいな事を書いていた書籍のタイトルと著者がわかる人おる？

お探しの書籍は、林晴比古（はやし はるひこ）氏による著作『C言語入門』（ソフトバンククリエイティブ／ソフトバンク出版）シリーズである可能性が極めて高いです。
林晴比古氏のプログラミング入門書（『C言語入門』や『BASIC入門』など）の「まえがき」には、プログラミング言語の本質をコミュニケーション（意思伝達）になぞらえた印象的な記述があり、以下のような趣旨の文言が記されています。
「言語とは、話者が言いたいことを表現し、聞く側（読者）がその言わんとすることを理解しようとすれば、それで十分にその役割を果たすものである。」
（※プログラミング言語も同様に、文法に捉われすぎず『コンピュータに何をさせたいか』という意図を伝えることが本質である、という文脈で語られています）

該当する可能性が高い書籍
書籍名： 『明解 C言語 入門編』または『新・C言語入門 シリーズ』（旧・『C言語入門』）
著者： 林 晴比古（はやし はるひこ）
出版社： ソフトバンク（SoftBank Creative）

著者の特徴と文脈
林晴比古氏は1980年代〜1990年代にかけて数多くのC言語やPascal、BASICなどの入門書を執筆されたPC黎明期のベストセラー著者です。
同氏の入門書の「まえがき」や「はじめに」では、次のような哲学が繰り返し語られていました。
単なる文法チェックや構文暗記に囚われないこと
「人間とコンピュータ（あるいは筆者と読者）」の間で意図や論理が正しく伝わることこそが「言語」の本質であること
もし昔読まれたC言語の緑色や青色の表紙の入門書（ソフトバンク刊）であれば、林晴比古氏の書籍で間違いありません。一度表紙や著者名に見覚えがないか確認してみてください。

AIの答えか
つまりAIは書籍を学習してると

林晴比古とか三田典玄とか昔の評判悪かった著者懐かしいな

でも、売れてたんだよね

評判悪かったのか。自分はC++入門向けの訳書で一度つまずいて、数年後に比古にゃん本を読了できたことで救われたよ

林はるひこはポインタの説明も構造体の説明も下手だよ

か○い本よりマシｗ

三田典玄の『入門C言語』は間違いが多すぎて改定版が出てたゾｗ

典玄はCマガジンだったかの連載で頓珍漢な主張カマしてて嫌いだったなぁw

こどもでお金なかったから
学校のパソコンでLSI C試食版のマニュアル読んで学んだ
あとでUNIXカーネルの設計読んだらいろいろつながって感動したな

>>803
こういう今井翔太みたいな人って今後スキル伸びるだろうな。苦労して学んだ経験、アハ体験って他の何よりも中毒性高いし

苦労して学ぶ行為が報われる
そんな時代が続くと良いんだが

>>803が優秀な AIを開発為遂げ、後にその AIによって淘汰されるのを見るのは忍びない

昔は図書館の本を読んで紙にプログラムを書くとか普通だったし、そういう遊びだった。
子供がやることなんだから将来のために苦労する意思があったわけがない。
むしろ苦労を感じるてるようだと伸びしろに期待できないと思う。 楽しくやろう。

され方にもよるが、自分が開発したAIに淘汰されるなら本望なところもあるんじゃないか
地球爆破作戦って映画でそういうことを考えさせられるシーンがあったな

少なくともC言語プログラマーにAI開発者は居ないんじゃね？

俺はAI（LLM）開発はFortranだな
cudaとの相性もcより良いし

cはcudaや並行/並列命令を指示するときディレクティブがめっちゃ面倒くさい

>>796
林氏、人気無かったんだ。よく見掛けたのは印象記憶ってだけか。
最近、氏の『明快入門コンパイラ・インタプリタ開発』ってのをやっと読み終わって、C系インタプリタの実装で入り組んだ再帰呼出しとかしてて『うん、俺には無理！』とか素直に思わせてくれる内容だった。
単純に、自作ゲームに簡単なスクリプト乗せたかっただけなんだけどね。

YoutubeでC言語はケン・トンプソンの発明だみたいなことを言ってる動画があった
Cの前身のB言語はトンプソンの仕事だけどCはデニス・リッチーの仕事なんだけどね
Cにトンプソンの思想が混じってるのは事実だけど誰が作ったかという話でトンプソンになるのはおかしい

論外の本は単に読まれないので評判を聞く機会はない。
林晴比古の本は定番の本と言えるくらいに人気があったけど定番の中では定番として紹介するのを躊躇うくらいの出来だなぁというくらいのポジション
……というのが私の理解だけど読んだことは無いので実態がどんなものなのかは知らない。

林は私的体験の範囲で本を書いている
エッセイくらいの気持ちで読めば良い

>>813
ケントンプソンと2人で開発したみたいのはよく見るな
なんでああなっちゃうんだろうな
この板でも何回か見たことある気がするし

C言語が特定企業の所有物にならなくて良かった

言語仕様を企業 (あるいは誰か) が所有することは出来ないことになってる。
強力な処理系を販売するなどして実質的な影響力を保持することは出来るかもしれんけど。

cが不自由になってたら代替プログラミング言語がでてもっと使いやすくなってたかもよ

トンプソンの最新言語がGO

Goはじっさいのところどうなの
わりと市民権得られてる気がするけど

私自身は Go を好きにはなれないので使ったことはないんだけどそこそこ人気が有るのは理解は出来る。
C ユーザが触るなら「こういうのでいいんだよこういうので」くらいの感じなんだと思う。

今気づいたんだが、餃子にはちみつをかけたらなんだか美味そうなイメージが浮かんできたわ

試してみたら？

マグロの刺し身にマヨネーズは
試したことがある

Goはトラブルが少ない
コンテナでなんか動かすならだいたいファーストチョイスだな

例外による緊急停止がないだけだろ
chdirのエラー無視しても動き続けるとかトラブルが少なくても怖いよ

今時分ストローマン論法は流行ってないからやめた方がいい
しかもエラーの原因はIDEの警告無視してるロートル開発者だし

>>827
diskfullでも動きそうな元気だなオイ

いまのところサーバー用途ではないだろうか
サーバー用途ではとても速いと言うか、比較対象が遅すぎる

CPU より I/O が律速だという前提でランタイムの I/O 部分のチューニングを頑張るけど最適化は頑張らない (そのかわりコンパイル速度は頑張る) という戦略が Go では上手くいってる。
サーバだと I/O が効いてくるような用途だから Go がマッチすると思う。
コンパイル速度が速いってのは想像以上に開発体験をよくすると評価されてるみたいだね。

大規模なプロジェクトはビルド通すだけで半日から下手すると数日
数時間以上かけてコンパイルエラーで終了は地味にきついですね

今では考えられないくらい途方もなく長く掛かってたよな

プリコンパイルヘッダやインクリメンタルリンクの爆速感に泣いた記憶

turboCって何故あんなに速かったんだろう

コンパイルする前にコーディングシート3回見直せって言われてたな

『何もできないC言語が好き。『猫でもわかるプログラミング』を30年運営する医師に迫る』
https://levtech.jp/media/detail_941/

初めてみたけど酷いなあ。
http://www.kumei.ne.jp/c_lang/index_c.html
http://www.kumei.ne.jp/c_lang/index_c2.html
テック系メディアが紹介すべき代物ではないだろ。

トップページに書いてある「中級者以上の方、セミプロの方、 プロの方ご遠慮ください。」は批判除けか。初心者にこそ見せてはいけない気がする。中級者以上には間違い探しのネタとしては良いかも。

代わりにサイト作ってここで公開してみて

てす

>>837
> インターネット普及期に数多くの初心者エンジニアを導いた老舗サイトです。
ダウト。聞いた事無いし、話題になった事すらない。

> 2000年代には書籍化もされ、『猫でもわかる』シリーズは累計50万部を超える大ベストセラーとなりました。
これも初耳。同様に、見た事も聞いた事もない。
とはいえ50万部は確かに売れてはいるのだろうが。

というかね、お前が何を目指しているかだけども、
中級者以上/セミプロ/プロ連中が見た事も聞いた事もないサイトや本が必要な時点で、
お前も中級者/セミプロ/プロにはなれないし、向いてないから諦めた方がいい。
ただ、趣味でやる分には勝手にしろではある。

俺はプロアスリートとして稼ぐ！、と言うなら、せめて小中学校では無双してから言え、ではあるだろ。
しかし運動音痴な会社員でも休日に草野球を楽しむのは全く問題ないし、草野球向けの指南書があってもおかしくはない。
だからそこに目くじら立てても意味無い。

ただそういう連中がプロに成れる事も、互角に戦える事もない。
プロ連中は、俺の体感だと4割以上は『K&R』だけで何とかなってるから、
『苦C』が必要な時点でかなり分が悪い。ただ、実際に『苦C』出身の連中は多分1〜2割くらいいる。
そして、この本やサイトは、先述の通り、中級者以上/セミプロ/プロ界隈では、聞いた事も、話題になった事すらない。

ただな、しょうもないサイトを探してきてアラ探しするより、お前が作りたいものをさっさと作れ、
その際に引っかかったとき、他に聞くあてがなければここで聞くのもあり、程度だと思うんだがな。
自分が何を目指して、何をするのか、もうちょっと考えた方がいい。
アラ探しで優越感で脳汁ブッシャーも、ドパガキにとっては一つの方法なのかもしれんが。

あらゆる事に言えるが、人数は初心者>>>上級者なので、ほぼ全部がゴミでごく一部がいいものなだけ。
ネット以前は魑魅魍魎には情報発信権がなかったので、ある程度の秩序はあったが、
ネット以後はこの辺も雲散霧消し、酷い記事やサイトはいくらでも作れるようになってるので、
「石ころ」を探す行為自体がまるで意味がない。Qiitaの記事を叩いてる馬鹿共はこれに気づけてない。
せめて「宝石」を探す努力をすべき。

まあ、サイト本体はチラ見しかしてませんけどね。
でも「最初の最初」はこの程度ではあるとは思うよ。
ただ、現在はこの「最初の最初」をCで始める意味が全くない時代なわけでね。

場末のプログラマだと知らないかも知れない

いちおう言っておくけど猫サイトは30年くらい前かな？
結構前からあったし俺は少なくとも当時から知ってるし
あの猫の画像もクソ懐かしい

この業界におってあの猫サイト一回も見たこと無いやつなんていないと思ってた

よく見てみると記憶蘇ってきた
Windows SDK編 第１部
これこれ！
win32書いてるときクソお世話になったのを思い出した

>>842
知障Ｚ乙。

>>843
> この業界におってあの猫サイト一回も見たこと無いやつなんていないと思ってた
今のお前に必要か？という事。

既に理解出来てる奴が、さらに入門書を読み重ねる意味はない。
『K&R』で問題なかった奴は、他入門書なんて読んでない。
俺も『苦C』なんて読んでないし、おそらくはちみつ餃子(>>814)もそう。
というか、理解したらさっさと進んでお前が欲しいものを作れであって、
何度も入門書を読んで「理解出来た！」と満足感を得続けるのは頭がおかしいだろ。

そのサイトがそれなりに充実して使えるようになる以前に、
対象レベルを通過した人達は、その存在すら気にしてない。
お前だって、今の小学生向けの教材が凄い事になってても、何も知らんだろ。

ただお前が猫で育って中級者以上/セミプロ/プロになったのなら、
お前がエール送ってやればいいだけ。少なくとも>>837では悪口書かれてるんだし。
俺は、見た事も聞いた事もない糞サイトを探してきて難癖付ける行為は意味無いから止めろ馬鹿タレ、と言っただけ。
ただ、そもそもあのレベルで良いも悪いも糞もねえとも思うが。

> 俺は、見た事も聞いた事もない糞サイトを探してきて難癖付ける行為は意味無いから止めろ馬鹿タレ、と言っただけ。


テック系メディアで一昨日の日付で紹介されてる状況理解しとらんわけねｗ

>>847
知障君は最終的に何が目的なの？

猫知らん奴秀丸も知ら無さそう

>>837見てトンチンカンな>>840投稿するID:4vUJSx4y0はマジモンのキチガイｗ

>>849
秀丸は知ってるし、使ってる連中も見てきてるよ。
俺はemacs派なので使った事無いけど。

まあ猫がそんなに有名なら、俺とは世代が違うんだろう。
2000年代にC入門した人達には有名なのかな？

>>850
自分の思考を言語化出来ない知障なんだな。

丁度話題になってるよ。
> ネットというかSNS流行りだしてから日本語を曲解したり読めないやつ増えたんだよ [194767121]
> https://hayabusa9.5ch.io/test/read.cgi/news/1791612388/
俺も「可視化されただけで増えてない」派だ。
リアルでは、自分と同程度の連中にしか会わないから、とんでもない馬鹿に遭遇する事もない。
逆にそこがネットの魅力なわけだが、言語化能力がない奴はウザイだけだな。
意見が合うかはともかく、意見が言えないようでは、存在価値無いだろ。

５ちゃんねるはリアルではない

>>837
> 初めてみたけど酷いなあ。
> http://www.kumei.ne.jp/c_lang/index_c.html
> http://www.kumei.ne.jp/c_lang/index_c2.html
> テック系メディアが紹介すべき代物ではないだろ。

目次ページじゃないか。
批判は的をしぼり具体的にすべき。

まだGoogleが無かった頃のデザインを残してるのだから、許してあげてよお

>>855 は >>837宛

>>855
それは阿部寛にだけ許された特権。イケメンは強い。

それで思い出したが、
> （※）当時は個人がドメインを取得するのは難しく、「粂井ネット」という団体を設立してドメインを申請したという。
> なお「旭川で独自ドメインを取得したのは、旭川市医師会に次いで僕が2番目のようです」とのこと。
これってもしかしてあのすんごかった病院のサイトか？と思ったが、違うな。

筆者が副院長してる病院が属する法人のサイトもそれなりにレトロ。
> https://henry-dunant.or.jp/index.htm
ただ俺は、今風の、オサレだがどこに何があるかぱっと見分からないサイトよりは、
この手の、モジモジしてるけど見りゃ分かるだろなサイトのほうが断然好きだけどな。
必要な情報への到達が断然速い。検索頼みは甘え。

>>857
後半部分の主張わかるｗ
オサレなスペースとかいらんのよ
省いて、まとめて、一覧性を高めてほしいんよ
何回もクリックさせられたり
何回もスクロールさせられたり
最後に「いかがでしたか？」みたいなのいらんのよなｗ

VS自体がクソ高かった時代に小学生のガキが無料で開発勉強するにはまずお世話になるサイトでした
今はもっと良い環境と資料がいくらでもあるというのはその通りです

>――そうして、「猫でもわかるプログラミング」が始まったのですね。サイトのトップページには「中級者以上の方、セミプロの方、プロの方ご遠慮ください」とまで言い切っています。なぜそこまで初心者向けに振り切ったのでしょうか？
>粂井：えっと、なんて言うんですかね。
>パソコン通信の時代にC言語の掲示板をよく見ていたんですが、そこではいつもですね、その……すごい、喧嘩が起きるんですよね。
>――技術的な正しさや、それぞれの思想による論争……でしょうか。
>粂井：そうなるとちょっと、アレなので。「本当に、初心者の方だけ見てください」ってことで、こういう建付けになったんですよ。

いいペルソナ設定だったと思う

100万人の信長の野望は、1件ほとんどの情報が詰まったメイン画面だが
実に無駄ばかりで醜い

猫とトホホは、インターネッツでのIT記述との偶然の出会いや小さな興味関心を育てるのに大きく貢献した。そんな位置付けな印象。

IT技術

とほほと猫とあと何個かあったような気がするんだけど思い出せない
プログラミングに限らず、なんか個人サイトにいろいろ助けられた思い出

>>864
DOBONじゃね？もう一個何かあった気がするが。

トホホはCに関しては知らんが、JavaScriptに関しては、
他のサイトが全部ゴミな事もあり、トホホだけはマシだった。
で、件の記事の下部のリンクから読んで、ああこんな人が書いてたのか、とは思った。

猫は俺はマジで知らない。
ただ、実際に有名ではあるんだろう。だからこそ記事に取り上げられ、また、売れたんだろうし。

>>859
猫:1996〜
MSDN公開開始:1998〜
VSEE(無料版):2005〜
なので1996-2005の頃にCを初めた人にとっては多分有用だったのだろう。
MSDNがどこまで公開してたか忘れたが、元々有料だったし、最初から今の様に全部ではなかったはず。
そしてその頃はネット環境も当たり前でもなかったし、
動作するコードを入手すること自体が結構手間だったから。

てかね、何だったか忘れたが、
SDKのコードもドキュメントのコードも通らず、どうしろと？な状況もあったし。
今はそういう無駄な苦労をせずに済むだけでだいぶマシな時代になってるよ。

>>860
実際それでいい。中級者以上なら公式(MSDN)見ろで十分だし。
サイトはそれ以前の初心者向けに「呪文だと思ってこの通り書いて動かせ」で、初手としてはこれで正しい。
ただこれだとSDKのサンプルコードを動かしてるのと同様だから、
さっさと次に行け、具体的には目的のアプリを作れ、ではある。

>>844
いやデザイナ使えよ、とは思ったが。
ただ先日、小学生の算数で手でグラフを描くのを止め、最初からExcelでやらせる、という話が出てた。
俺はこれには反対で、小学生のうちは手でグラフ描いとけよ、そうじゃないと二度と描く機会はないし、
Excelなんて中学生以降で十分、と考えてる。
これと同様、ズブの初心者がデザイナを使うのは邪道！とでも思ったのかね？
ただデザイナ使わないとVisualな意味無いんだが。
俺はXWindowの呪文を手打ちさせられた経験があったので、初めてVC使った時は感動した。

じじいは話が長い

Ｚは死ね

c言語ソースは3行以内に書かないとな

WisdomSoftとかProgramming Placeとかもよく見てた

何故秀丸マウント？(>>849)と考えてたが、なるほどIDEを否定してる旧人類か。
IDEで「新規プロジェクト作成…」のウィザードに従ってOKしていけば>>844の内容は5分で完成する。勿論当時のIDEでも。
よって、正しくIDEを用いた連中はどんどん先に進める。
一方、お前らは無駄に一日かけたから、今も無能なままなわけだ。
お前らが俺のアドバイスなんて聞くとは思えないが、それでも(外野のためにも)一応言っておくと、

IDEは最初から使え。初心者ほどIDEの効果が絶大だ。
最初からプロ用のIDEを使え。今ならVSかVSCodeだ。初心者用のIDEが偶にあるが、ゴミだから無視でいい。(ていうかバグが多い)
初心者のうちは、IDEの全機能を使おうとはするな。お前にとって便利な機能だけを使えばいい。(※)

ただまあ、2000年頃は実際、IDE否定派、IDE使うな、テキストエディタで書け、って奴も割と居た。
今はもうそういう連中はほぼ死んだと思うが、そういえば、連中の推しテキストエディタが割と秀丸だった。
だからIDE否定派の旧人類には猫は割とフィットするのかもしれん。
ただ明らかに時間の無駄だがな。

※
なんでも形から＝プログラミングに於いては文法から入ろうとする奴は居る。
C/C++はこのタイプとは絶望的に相性が悪く、
C: 文法が軽すぎて、全部抑えた後にも何をすればよいか分からず迷子になるから、
C++: 文法が無限にありすぎて終わらないから、だったのだが、
ゆとりZの場合は、追加で、
C: 現代的には使用禁止の文法も「これ知ってる俺スゲー」のマウントネタであり、(>>770)
　結果的に、廃止すべき糞文法を駆使した糞コードを凄いものだと勘違いしてるから
という、おかしな事にもなってる。(なおこれは何度も繰り返してるので俺はもうスルー気味)
が、これはさておき、このタイプはIDEの全機能を網羅しようとして嵌ってしまう。
初心者がプロ向けの全機能を理解できることはない。
で、おそらく、こういうタイプの為の救済策が、
・初心者用IDE(初心者でも分かる機能しか搭載してない)
・IDE使わずにテキストエディタ(だって他機能が無いのでよそ見されない)
なのだと思うが、これは結局、一部の馬鹿に付き合わされてるだけだ。
IDEを用いれば、特に初心者の頃の上達速度は何十倍にも上がる。最初からIDEを『正しく』使え。
(逆に考えると、IDE否定派は、その本人がこのタイプなのかも。
この意味では、自分と価値観が似てる筆者のサイトや書籍を参考にするのが上達の早道とはなるが)

初期にPWB試してから
二度と使わないと心に決めた

>>870
> WisdomSoft

これなｗ　これこれ、これも見てたわ
printf("Kitty on your lap\n");
こういうのなぜか覚えてる

あとperlで何か見てたサイト二個くらいあったはずなんだけど
まったく思い出せないし、検索してみてもひっかからないし
緑っぽい背景で余計なスペースがないみっちりしたタイプのページだったような

>>865
DOBONは知らんなあ
とほほはHTMLを見てたなあ
懐かしいね

>>873
ジジイ、インテリセンスで成仏しろ！！！

ずっと長文垂れ流してるのもしかしてこの人？

日常の進捗履歴記録ツールWitBucket(仮称)検討中
https://mevius.5ch.io/test/read.cgi/tech/1668901194/

>>875
DOBONは、猫と同時期の、2000年前後頃に有名だったサイト。
MFC+Win32APIでVBとVCのサンプルコードを大量に掲載してた。
その後MFC(1992)は.NET(2002)に代わられるが、
DOBONは.NETに対応しなかった(サンプルを載せなかった)のでオワコンとされた。
ただ、今見ると中身は全部.NETになってるが。

MFC/Win32API/.NET/VB/VCなので、
C言語そのものではなく、Windowsフレームワークの使い方を解説したサイト。
ただ猫も
> 「ＤＯＳのプログラムは、作れるがWindowsのプログラムは ちょっと・・・」
の通りWindows向けで時期も被るので、あるいは、と思った。

ただDOBONはMSDNが公開されればお役御免ではある。
ところでMSDNにはC言語入門講座はないのか？と思ったら、まあまあのが出てきたぞ。
https://learn.microsoft.com/ja-jp/cpp/c-language/if-statement-c?view=msvc-170
ゆうてまあ、リファレンスだから、入門者向けではないか…。

昔はウェブ検索がカスだったので個々の部分での正確さが欠けていても網羅性が高い (幅広く説明している) サイトのほうが利用しやすかったという事情はある。
もちろん正確に網羅的であればそのほうが良いけどさ。

CじゃないけどJavaならMLがクッソ役立った
高木さんがやってたJavaHouseのトピックスごとにまとめてくれてるの夢中になって読んでた
いろんなジャンルの人が本名所属丸出しで議論するのはアツかった

そもそも猫もそうだけど「学習」が目的なわけでIDEで一発だってのは勉強する気あるの？って思う
今は電卓あるのに九九覚えるのは無駄と言っているようなものではないだろうか？

「これからはAIの時代みたいだからお役御免の私のHPは閉鎖(凍結？)します」みたいな人がいたかと思えば、猫の人は「自分の記事は古くて現代の環境ではうまく行かない内容もありますが、そこはまあAI活用で補完してください」と言っていて、物事は捉え方次第だね

つまり猫でも〜の写経主義がクソって言いたいわけね
それを時代無視して言われてもな
C++というかwin32apiにどう立ち向かうかって部分で勇気づけられた人は多いだろう
金ある人はペゾルドの本読んでMSDN買ってただろうし

やはり、ここは、make 一発でしょ

unixのシステムコール系って勉強するところあった？
層がぜんぜん違うか

>>879
この状況でそれは、さすがに対象が分からない。
各社各様、正確性も網羅性も目指してる。そもそも、100%が目標でもないし。

だいたい、正確性と網羅性の頂点に君臨するのが『K&R』だ。(なんぜ準仕様書だし)
ただあれでは無理な奴も多かったからみんな噛み砕いてグダグダ説明してるわけでね。
勿論冗長になりまくって分量は多くなるが、それでも感謝してる奴が多いのも事実だろ。

直前、つまり俺宛で、MSDN等の公式リファレンスの類を全部読んで入門書の代わりにする事に対してなら、
正確性と網羅性においてはリファレンスの方が断然上だ。
(だから反論になっておらず、誰宛？となる)

>>881
電卓有るから九九要らん＝Excelあるからグラフを手で書くのは無意味
学習過程でIDE使ったら無意味＝運動中に水分補給したら運動の意味無し

IDE使え＝本来業務に集中しろ
プロがIDE使うのはこの目的なので、『正しく』使えれば自然とこうなる。

>>883
> C++というかwin32apiにどう立ち向かうかって部分で勇気づけられた人は多いだろう

わかるわ〜　なんせ情報のない時代
win32？　HWND？　LPCTSTR？　はああ？？
みたいなときにあのとぼけた猫の顔がいっときの清涼感になったねｗ

オレに聞けスレで、
誰も聞いてくれてない

>>886
誰に対してでもない。 強いて言えば話題に対して。
正確性や分かり易さなどが要素として挙がっている中で網羅性という軸もあってそれが大事だった時代もあるという提起。

>>885
マニュアル(本あるいはmanコマンド)の2章がシステムコール
マニュアルがあることを知るのは自分の場合は本で、UNIXプログラミング環境だった

猫の粂井さんが1955生まれで
とほほさんが1965生まれなんだな

(｀･ω･´)ゞ

団塊の麓辺り

>>883
コピペ出来るから、サイトの写経主義自体は実害はないが、
問題はそこではない。

初心者は「このコードがどう動くか」に注力すべき。
突き詰めればインタプリタであり、実際、その方がいい。
PHP: https://www.php.net/manual/ja/control-structures.if.php
Python: https://docs.python.org/ja/3.15/tutorial/controlflow.html#if-statements
猫: http://www.kumei.ne.jp/c_lang/intro/no_12.htm
他言語では今書いたコードがどう動くかに完全に注力出来る。
Cでテキストエディタスタートなら、ファイル拡張子ガー、文字コードガー、BOMガー、コンパイルガー、の説明も必要だが、
IDEでハロワプロジェクトを改造すれば、この辺すっ飛ばせる。
セーブせずに実行ボタン押しても、自動的にセーブしてコンパイルして実行してくれる。
だからIDEは準インタプリタ程度にはなる。

そして猫は明らかに脱線が多い。
ただこれには相性があり、脱線先での情報取得も楽しめる奴
＝百科事典やwikiでリンク辿って延々読み続ける奴にはフィットする。
だから一概に悪でもないが、人は選ぶ。

ただそもそも、写経する時間があるなら、
その手本コードがどういう意味なのかを理解する時間に充てるべき。
コードはコピペでいいから、そのコードの説明をしろと。

すると、「そのコードは不要だろうが！」という、もっと糞な事実に直面する。
CのGUIでのmainは初期化＆イベントループのエントリだが、
これはフレームワーク/ランタイムがユーザーコードにはみ出てきてるだけで、
正しくコード配置されていれば不要だからだ。
実際、JavaScriptにはmainが無く、onclick関数の中身をいきなり書ける。
(CのGUIでのmainの中身は、JavaScript標準内に実装されてて、ユーザーが書く必要がない)
つまり、GUIをCでやる事自体がそもそもの間違いなので糞コードが発生し、
さらにIDE使わないから写経するハメになるという、
ドＭプレイを猫やお前らはやってる。
まあそれを楽しむのも自由だが、何も知らない初心者にも強要するのは酷い。

IDEはこの辺の、言語が糞な点を補う効果もある。
デザイナでボタンを配置してダブルクリックすれば、
onclick関数のスケルトンが自動生成され、そこにカーソルが当たった状態のエディタが開く。
結果的にプログラマの負担はJavaScriptと同等レベル迄下げられる。(勿論当時のIDEでも)

ただCでGUIやるのは本当に糞だ。
Qtとか知らんが、言語の問題(階層記述能力とクロージャ)なので、どうにもならない。
2000年代頃は論外だったJavaScriptが台頭してきたのは実力だ。
GUIやるなら今はJavaScriptしかない。
勿論2000年頃はCでGUIも一般的にやってたから、この点は猫が悪いわけでもないが、
猫はその当時でも出来た事をやってない。精神論で老害丸出しだ。(老害なんて言葉は当時なかったが)
とはいえ>>881のような精神論者にはフィットするし、実際お前らが助かったのならそれでいいが。

ていうか、猫で助かった連中の環境って何だったんだ？
猫はVC++(勿論当時は有料)使ってるので、なら普通にIDEの機能を使えとしかならない。
もしかしてgccやフリーのコンパイラでWindowsプログラミングする手段が有り、
IDEで自動生成されるコード自体を掲載してるサイトが有益だったのか？

>>890
そこが引っかかるのは、お前がプログラマではないからだ。

プログラミングは、あくまで何かを作る手段であって、目的ではない。
同様に、手段(技能)を鍛える教育の、小中学校での技術/家庭科が参考になるだろう。
技術/家庭科においては、必ず、何か最終成果物を作ろうとしてただろ。

例えば家庭科で「ホットケーキ」を作る時を考えよう。
いやそれが料理か？という程度だが、それでも、
「ホットケーキミックス」に「卵」を「割って」入れ、
「水」も「計量」して、「泡立て器」で「かき混ぜ」、
「コンロ」上の「フライパン」で「焼き」、
「フライ返し」で「ひっくり返し」て「完成」という、
材料を用意し、それぞれの道具を適切に使い、成果物を得る、というシーケンスを繰り返し、
使える道具と経験値を増やして行く。
これが一般に手段(技能)を鍛える手法であって、網羅性なんて必要ない。
目的を達成する為に、必要な手段を、その時々でインストールしていく。
包丁が一丁前に使えるまでは料理してはいけない、なんて事はない。
カンナを綺麗にかけられないうちは、ノコギリを使ってはいけない、なんて事もない。

言語も同じ。漢検一級受からないと日本語使ってはいけない、ということはない。
語彙が無かろうが下手だろうが、意思疎通の努力をすべき。
(下手でもしゃべらないと何も始まらねえんだよ！ってのは英語シチュの方が分かりやすいかも)

プログラミングも同じ。
言語の全文法を抑えてからでないとアプリを作ってはいけない、なんて事はない。
DOSプログラミングは出来ても、GUIが出来ない内は、アプリを作ってはいけない、ということもない。
お前が知ってる文法の範囲でいいから、お前の作りたいものを作れ、だ。
ユーザーには、アプリがどの文法で書かれてるかなんてどうでもいい。
GUI作りたくなったときにGUI文法/手法のインストールでいい。
これがプログラマの目線だ。だから網羅性が話題にならない。

とはいえ、効率よく技能を得ようとすれば、纏めて鍛えるのがよく、
料理学校では最初から包丁を練習し、各種料理も一通り作りまくる事になる。
お前らがやってるプログラミング学習も大体これで、
最初からほぼ全文法を網羅的に学習するわけだ。
ただしCの場合は糞文法が混ざっているので、ゆとりZがおかしな方向に走ってるのは前述の通り。
正しくは、糞文法を除外した範囲で学習すべき。実際大学ではそうしてる。
(といっても先生頼みだが。
だから初心者が自学するならgoogle等大手のコーディングルールを参考にすべき。
つまり逆に考えれば、糞文法をドヤってる馬鹿共は正規のプログラミング教育を受けてないって事なのかね？
まあ実際、専門学校や大学で先生に聞けるなら、ここに来る必要はないし、来るべきでもない)

技能において網羅性が問題になってくるのは、中〜上級者からだ。
日本語なら、相手の使った単語の意味が分からないと困るので、人並み以上の語彙と漢字能力は必要となる。
料理なら、一般的な食材と処理方法等を知ってないと、話が通じなくなってくる。
プログラミングでも同様で、他人のコードを読む機会が増えてくると、
それが妙な文法で書かれてても、読めて、修正指示出来る程度の能力は必要になる。
だからまあ、技能と網羅性のバランスで、大体どういうタイプのプログラマか分かる。

さて、はちみつ餃子、お前は以前、コード構成についての話が全く通じなかったから、中〜上級者プログラマって事はない。
プログラマの目線も通じないようだから、どうやらプログラマでもない。
それでも網羅性がそこまで気になるのなら、ただの「文法コレクター」か、
或いはもう一つの軸である、「コンパイラ屋」といったところか。

プログラマは最小文法のみでもアプリを作れるが、
コンパイラ屋は最初から全文法を抑えないとコンパイラが作れない。
かくして、
プログラマ: ろくにコードも書けない癖に偉そうに！
コンパイラ屋: ろくに文法も知らない癖に偉そうに！
とお互いに思っているので、大体仲が悪い。
はちみつ餃子には、一般プログラマとしては不要なレベルの仕様/文法知識があるが、
実際のコードの話がまるで通じない。(コーディング能力自体は低い)
これは、初手から全仕様/全文法が必要な「コンパイラ屋」ならあり得る。

そこで質問だが、可能なら答えてくれ。
件の糞文法について、
> and on many targets implies a speed and code size penalty on global variable references.
> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fcommon
つまり速度とサイズに難あり(なので出来れば使うな)なのだが、
いや、グローバルと認識出来るならBSSに配置出来るだろ、出来ないのはコンパイラの手抜きじゃねえか？と思える。
何か仕様/文法的に無理な理由があるのかね？
なお当該タイミングで聞かなかったのは、
プログラマ目線だと、そもそも糞記述を修正(static/externを書く)すれば済むだけなのと、
ドヤ馬鹿にさらにネタを提供してドヤ馬鹿再生産に加担したくなかったから。
ただ、糞文法は糞文法として、gccのこの言い訳も気になってたので。(とはいえ単なる興味程度だが)

今日も暑かったかな？

長文書いてるほど暇なんかな？

今なら言語覚えても低スペックなら開発環境もインストールできない

話す相手おらんのやろな

写経や歪んだ使い方のネットを止めれば、お前らにももう少し時間が出来るだろうよ

>>901
AIに作文させてるだけ

劣化がむごい

>>903 やめたれｗ

>>854
> 批判は的をしぼり具体的にすべき。

http://www.kumei.ne.jp/c_lang/intro/no_01.htm
> #include <stdio.h>
> main()
> {
>
> printf("This is a test!");
>
> }

のっけのコードがC99以降で文法違反になるシロモノをいまどき紹介するもんではないだろ。
https://godbolt.org/z/vrvb9shEW

>>871
> だからIDE否定派の旧人類には猫は割とフィットするのかもしれん。

「猫でも〜」はMicrosoft Visual C++1.51のIDE使って説明してる。

>>908
>>896

>>908
1996と1999の大きさも比較できない知障Ｚはプログラミング諦めろ。

> 1996と1999の大きさも比較できない知障Ｚはプログラミング諦めろ。

メンテの概念なくて草ｗ

>>908
更新日が書いてあってその時点では妥当性があるのだからその点については誠実だろう。
三十年前だとさすがに古いと判断できない読者のほうが間抜け。

ただ、規格には改定があるものだということくらいは追記したほうがいいかもね。

内容が古くなって更新もされてないものをいまどきになってテック系メディアが紹介してるのがクソってことよ。

>>913
ただのインタビュー記事で、今使えとも言ってないし、
実際当時は役立ったとして懐かしむ連中がこのスレにも複数居たし、記事として採り上げる判断は妥当。
記事のチョイスが気に入らないなら、お前がそのメディア読むのを止めればいいだけ。

歴史的遺物として取り上げているように見えるし、テック系メディアがテックの歴史を語って悪いということもなかろう。
テクノロジーは新しいものだけで成り立ってるわけではない。

それを言っちゃあお終いよ

>>916
普通の人なら分かる事を理解出来ないから知障なのであって、明示的に言うしかない。
それでも通じないとは思うが、それでも言い続けるしかない。

ていうかね、Ｚ価値観の物はＺにしか作れないのよ。Ｚはまだ若すぎるのか、この辺の覚悟が足りない。
ジジイの与太話に興味ないのは自由だが、読者に与太話を懐かしむ奴が多ければそれは記事として成立する。
そんなの要らねえんだよ！なら、この価値観を共有するＺ同士で連携して新しいメディアを立ち上げるしかない。

同意を得られずブチ切れて逃亡な、毎度のＺ仕草だと思ってたが、>>908で復活してきたのは少し驚き。
ただ、5chではどうやってもＺが望む展開にはならない。
この辺、Ｚ世代で、「ぼくのどんなふまんにもきょうかんしてくれるやさしいさいと」を立ち上げれば、
少なくともお前らＺにとっては、もの凄く「きもちいいさいと」になって大受けするだろうよ。
それでいいのかは分からんが、それでも俺は立ち上げるべきだとは思うよ。

>>914
> 今使えとも言ってないし、

言ってんだよなあ。


https://levtech.jp/media/detail_941/
> ――では、Visual Studioの最新版の環境構築について2026年に更新したのはなぜでしょうか。
> 粂井：僕のサイトでは、ずっとVisual C++、ひいてはVisual Studioをベースに解説をしてきたんですよ。でも昔のバージョンのVisual Studioって、今はもう手に入りにくくなっていますよね。
>
> ですから、もしもこれからプログラミングを始めようとする人が僕のサイトにたどり着いたとき、最初の開発環境の準備でつまずいてしまったらもったいないなと思いまして。一番最初の「とりあえずコンパイルして動かす」という体験がすぐできるように、新しい開発環境が出たら、その設定方法だけは載せるようにしているんですね。

>>918
それが以下ページを指すと読み取れないお前みたいな知障Ｚはプログラミング諦めろ。
http://www.kumei.ne.jp/c_lang/vs2026/project.htm

てか割とマジでな、何でもだが、最低限の国語力はないとアカンよ。

> それが以下ページを指すと読み取れないお前みたいな知障Ｚはプログラミング諦めろ。

「ぼくのサイトはVisual Studioを使って説明してるよ。最新版のインストール方法は更新してるから参考にしてね。」と言ってるのが読み取れないアホかあｗ

どうでもいいけどこのBOMつけてるのは何の意味があってやってんだろ

>>920
うむ、お前は煽り抜きでガチの知障、5chでよく言われるASDなのだろう。
その言葉の明示的な意味しか解釈できないパターンか？

> 「ぼくのサイトはVisual Studioを使って説明してるよ。最新版のインストール方法は更新してるから参考にしてね。」と言ってる
これは明確に間違っていて、正しくは、以下。
「僕のサイトは昔のVSを使って書いてるので、
『勿論同じ昔のVSを使えばそのまま動くのだけども、』
今は昔のVSを入手しづらいから、入手可能な最新版での最初の手順だけは示しておくよ。
『だから後は色々違うかもだが頑張ってちょ。AIの時代だし、何とかなるべ〜』」
お前は上記2箇所の『』内を補完できてない。多分ASDのどれか。

ただ、国語力の問題であれ、実際の障害であれ、或いは単に興味の問題であれ、いずれにしても、
そのメディアがお前に合ってないのなら読むのを止めるべきだよ。
ASDならASD向きのメディアに切り替えるべき。あるのかは知らんが。
国語力の問題ならさっさと鍛え直せ。お前の国語力は小学生以下だ。
ただこれ、行間というほどの行間ではなく、論理的整合性から妥当に推定できる範囲なので、
これが出来ないお前はやはり知障なのだと思うよ。
(常人が苦も無く出来ることが出来ないのは障害、常人が勉強等の苦労をして出来るようになった事が出来ないのはただの勉強不足)
ただ、ASDだからってプログラミングに向いてないわけではないらしいが、
この辺の国語が通じないレベルだと、話しててウゲってなるのは事実。
最近はこの辺大雑把に「コミュ障」とくくられちゃってるけどさ。

昔のPHPってCで書かれてるん？現行の8？とかも？

Visual C++ (Visual Studio) の C は今でもデフォルトだと C89 (に独自拡張を追加したもの) だよ。
https://learn.microsoft.com/ja-jp/cpp/build/reference/std-specify-language-standard-version?view=msvc-180#c-standards-support-1
https://godbolt.org/z/Kq6f3W1s9