C言語なら俺に聞け 159

2022/08/04(木) 23:32:27.83

!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

C2x ドラフト
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.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言語なら俺に聞け 158
https://mevius.5ch.net/test/read.cgi/tech/1640401906/

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

2022/09/19(月) 16:49:03.30

それにUTF-8にはバイトオーダーがありません

2022/09/19(月) 16:50:38.05

>>269
規格上、BOMのほうが優先される。
BOMがある場合、エンコーディング走査アルゴリズムは呼び出されない。
BOMをつけましょう。

2022/09/19(月) 16:52:03.62

BOMをつけないとセキュリティ上の問題がある。

2022/09/19(月) 16:52:15.94

付けたWebサイトをここで公開して下さい
楽しみにしています

2022/09/19(月) 17:25:06.78

すべてのUTF-8にBOMがついてたらSJISはもっと早く消えてくれたと思うんだよね

2022/09/19(月) 17:31:57.08

この話題は、BOMをつけましょうということで、良いのでは？

**ハノン** ◆QZaw55cn4c (US 0H7f-G1yF) · 2022/09/19(月) 18:02:53.27

>>276
違います
BOM を付けるべき正統な理由がある時には付け、特に理由がなく惰性で付けてるんだったらやめよう、です

2022/09/19(月) 18:05:47.85

BOMを付けていない人を見かけたら、注意して差し上げましょう。
ということで、良いのでは？

2022/09/19(月) 18:12:09.41

テキストファイルを開いたとき最初の三文字がゴミかどうかいちいち判断するの？
2つのテキストファイルを結合するときゴミをひとつにまとめる処理するの？
BOMという考えが誤りなんだよ

2022/09/19(月) 18:14:42.87

法令でBOMを義務付けるべきでは？

BOMが無かったら通報するみたいな。

2022/09/19(月) 18:15:00.74

Windowsの一部アプリでBOMがないと動作不具合起こすんだよ
Officeとか、Officeとか、その辺
この辺への思いやりが必要な時は付けてあげると良い

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 18:19:47.40

>>278
それに加えて BOM を無駄につけている人を見かけたら、注意して差し上げましょう、も追加してください。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 18:20:53.56

>>280
その法令は間違っていますね

正直いって、規格で決めればいいとかいう思考停止にも我慢ならないんですよ
美しい世界（爆笑）のために今日もがんばります！

2022/09/19(月) 18:22:38.11

>>279
ふたつのテキストファイルが Unicode である保証もない。
メタ情報で保証があるなら BOM があっても困らないし、
保証がないなら BOM があろうがなかろうが困る。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 18:23:22.11

>>281
たしかに office とか office とか office とか office とかに思いやりを示す寛大な処置ということであれば、付けて差し上げることにやぶさかではないのですけれどもね

2022/09/19(月) 18:27:12.50

>>277
後半に関して言えば、そのテキストがどのエンコードを用いているかが他の手段で示されているなら
BOMは用いるべきではないとされているからそれに従えばいい話だね。
「俺が扱うテキストは全部UTF-8に決まってるんだからBOMは要らない」という自己中心的な主張と
混同してくれなければいい。

2022/09/19(月) 18:28:42.31

まあ私はどちらでも良いんですけれども。
（レイヤード・ストリームをつこてますので）
gccがBOMに対応したのだから、BOM付ける陣営の勝利では？

2022/09/19(月) 18:33:34.93

ところで明日は地下鉄が止まるかもしれないので、調べておいた方が良いですよ。

2022/09/19(月) 18:35:51.09

わたくし思うのですが、BOMに対応しないソフトウェアを企画してしまう技術者って、もはや技術者で無いのでは？
ユーザーが必要としてるわけですからね。

2022/09/19(月) 19:59:29.61

WindowsはBOMがあった方が判別しやすいが、LinuxやUNIXはBOMがあると余計なものが付いているという感じになる。

マルチバイト圏への配慮が足らなかったマイクロソフトが一番悪い。

だいたい2バイトで漢字がすべて収まると思ったアメリカ人に対して、早く日本人が漢字は何万字もあると教えなかったのが失敗だった。

2022/09/19(月) 20:35:04.98

BOMキチガイども

2022/09/19(月) 20:42:51.60

MS-DOSの頃は、これで十分って思ってたからな。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 21:05:32.45

>>290
＞だいたい2バイトで漢字がすべて収まると思ったアメリカ人

CJK 漢字統合なんて醜い仕様のひと言に尽きますよね

>>286
自己中心的、という言葉の使い方が間違っていますよ
その昔は Shift-JIS, JIS, EUC が入り乱れまくっていましたが、だれもテキストデータにエンコードを示すプリフィックスを付けようなどとは思わなかった事実があります
UTF-8 にバイトオーダーマークなんか絶対に不要なのにバイトオーダーマークを安易につける発想そのものが自己中心的なのでは？

美しい世界（爆笑）のために今日もがんばります！

2022/09/19(月) 22:08:36.69

「俺が扱うテキストは全部UTF-8に決まってるんだからBOMは要らない」というのが自己中心的な主張だと言ったんだが？
こんな単純な日本語の文章すらまともに読解できない奴に間違ってるとか言われても困惑するわ。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 22:24:33.90

>>294
同じことを繰り返しますが、
①過去、エンコードの違うテキストを各種取り扱っていたからといって、「テキストの内部に恣意的にエンコードを示すマークを入れる」などという自己中心的なことをした歴史はなかったのです。
　特にそういうことをしたいときは、ソースコードにその言語のコメントでエンコードを示す、くらいの配慮をしていたものです
②UTF-8 でエンコードされている限り、そのコンテンツがアスキーコードのみで構成されているのならば、特にバイトオーダーコードは不要で、as is で使えるように、欧米諸国に配慮した設計です

特に②が重要で、バイトオーダーコードを要れずとも、C のソースコードは UTF-8 であれば普通にコンパイルできる、はず、なのに、なぜわざわざバイトオーダーコードを付加して既存の処理系がそのままでは使えなくなってしまったのか？
コンパイラは MS-VC だけではなく、gcc も clang も lsi-c （ｗ）もあるというのに、既存のコンパイラの動作を妨害してまで、バイトオーダーコードを付加するエディター側の方が自己中心的といえるのではないでしょうか？
そしてエンコードを示すマークなどではないバイトオーダーマークをエンコード種を示すマークに乱用するしている二重の矛盾も指摘しなければなりますまい

私の言っていることがわかりますか？

2022/09/19(月) 23:05:07.14

>>264
そのHEADの箇所に行くまでエンコードが分からないのだよな？
そこまでどうやって読むのか？
まあ、現実問題としてASCIIで入れておきゃいいわけだけど、厳密にはそれじゃいかんよな。

2022/09/19(月) 23:10:53.08

>>290
エンコード切り替えの規格は ISO/IEC 2022 がある。
PC-9801 時代あたりにはマニュアルで KI/KO コードという名前で説明されていた。
ヨーロッパ言語も ISO/IEC 8859 として十種類以上の文字セットが定義されているんだ。
日本での事情以上に混在は深刻な問題であって、対処する規格は当然ある。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 23:18:33.90

>>296
おっしゃるとおり、そこまでは、ただのアスキー7bit で記述するんですよ
大概は第一行目にエンコード種をアスキーで書くものでしたけれどもね
厳密っていうけれども、あなたのおっしゃる厳密の意味がよくわかりませんね

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 23:19:31.82

>>297
英語が一番簡単で、ウムラウトとか苦労していたと思いますよ、ウムラウトは確か 7　ビット領域に侵食していたような気が

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 23:23:44.77

>>297
おっと、私のいっていたことが少し不正確でしたね、たしかに　KI/KO は生 JIS にありましたね

2022/09/19(月) 23:40:42.70

自然言語なんて数千年単位の歴史的経緯の塊だ。その文字も。
綺麗に整理しようとしたって元がグダグダなんだからどこかしらでグダグダになる。
そんでそのグダグダをひとつに寄せ集めたのが Unicode なんだぞ。
そりゃグダグダで当たり前だし、そういうもんだと思うしかしょうがないだろ。

そんでもって Unicode がかなり広まったといっても従来の文字コードが消滅したわけでもない。
https://xkcd.com/927/

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 23:43:18.98

>>240
チャイナ規格ですか‥‥（差別意識満々）
調べてみましたが基本的に4ビット固定長であり、UTF-8 を包含してはいないようですね、UTF-8 の上位規格というのはどういう根拠でそういっているのですか？
どっちかというと現行中国漢字エンコード規格の上位規格でしょう

私の理解
・7 ビット圏は 1 バイト
・拡張部分は可変長ではなく 4 バイト固定
・現行の中国の漢字エンコード規格 GBK（シフトJIS と同じ仕組み）を包含するように第二・第四バイトの範囲を GBK と被らない範囲に制限している。

2022/09/19(月) 23:48:55.05

>>302
ユニコード・コードポイント全てを内蔵したうえで、さらに少数民族の文字を追加してあるからでしょ。
そういう生い立ちなんだから。

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 23:52:42.86

>>301
How standards have been overproducted とか易しい英語にしてほしいなあ

**デフォルトの名無しさん** (US 0H7f-G1yF) · 2022/09/19(月) 23:55:05.42

>>303
コードポイントの数は十分確保している、って言う意味で「ユニコードの上位規格だ」と主張しているわけですか
この理解で正しいですか？

2022/09/19(月) 23:55:54.72

EBCDIC なんていうコード体系もあるんだよな
これはASCIIよりも古い
このコードで動いていたPCもあった（今もあるかは知らない）

2022/09/20(火) 05:35:11.57

N5200か

2022/09/20(火) 05:38:15.50

>>290
2千字の常用漢字で済ませという時代だったから。

> だいたい2バイトで漢字がすべて収まると思ったアメリカ人に対して、早く日本人が漢字は何万字もあると教えなかったのが失敗だった。

2022/09/20(火) 07:29:23.63

>>295
ここまでくると狂気しか感じないが。>>286で自己中心的と書いた内容と全然関係ない内容を
延々と繰り返すのはなんでだろう。
ついでに>>295の内容について言えば、規格で定めているもののどこがどう自己中心的なんだか。
この場合の「自己」って誰のこと？

2022/09/20(火) 09:59:52.88

>>270
PHP+SJIS全盛の頃にBOMの代わりに「美乳」が使われてた時代があったな

2022/09/20(火) 10:02:30.30

>>275
そうかな
全てのファイル名にBOM付いてたら嫌だな

2022/09/20(火) 10:04:55.52

MSならやりかねない

2022/09/20(火) 10:08:20.39

>>311
asciiなら不要だよ

2022/09/20(火) 10:19:31.19

>>313
BOM付けろ派はASCIIかどうかもBOM付いてないと判らないみたいだし

2022/09/20(火) 10:27:10.48

MSの事だから、UTF-16使いそう

2022/09/20(火) 22:46:15.84

>>309

＞>>286で自己中心的と書いた内容と全然関係ない内容

>>286
＞「俺が扱うテキストは全部UTF-8に決まってるんだからBOMは要らない」という自己中心的な主張と混同してくれなければいい。

まあ、活動家のなりきりをしているので、そういうスタンスをとっているけれども、本質的には

>>295
1. 過去、エンコードの違うテキストを各種取り扱っていたからといって、「テキストの内部に恣意的にエンコードを示すマークを入れる」などという自己中心的なことをした歴史はなかった
2. UTF-8 でエンコードされている限り、そのコンテンツがアスキーコードのみで構成されているのならば、特にバイトオーダーコードは不要で、as is で使えるように、欧米諸国に配慮した設計

が言いたいことですね

UTF-8 ならば通常は as is で使えるんですよ、特に C/C++ のコード（コメントは英語・これって普通でしょ？）をそのまま使えるのに、どこぞのエディターが勝手につけるバイトオーダーマークまで正当化する風潮に苛立ちを感じているんですよ
長いものに巻かれよ、みたいなみっともない風潮を正当化するあさましさにあきれ果てているのです

あなたがそうだ、とはいいませんけれどもね

2022/09/20(火) 22:50:52.98

どこでも演説をおっぱじめるガキにいらだちを感じてる

2022/09/20(火) 23:07:44.32

多国語が混在しても扱えるところが気に入ってる

2022/09/21(水) 00:15:08.73

gdbについて質問いいですか？
ステップ実行でfopenを通過しようとすると
　"iofopen.c: そのようなファイルやディレクトリはありません"
とメッセージがでて先に進めません。どうすれば回避できますか？

OS:Linux

2022/09/21(水) 00:17:32.94

ちなみにソースは以下の感じです
fopenで開くファイルは実行ファイル(a.out）と同じ場所に置いてあります。

#include <stdio.h>
void main(void){
　FILE *fp;
　fp =fopen("aa.txt", "r");
　fclose(fp);
}

2022/09/21(水) 00:45:37.65

このあたり参考にしてください
https://doss.eidos.ic.i.u-tokyo.ac.jp/html/advanced_gdb.html#libraries

2022/09/21(水) 06:00:40.75

>>321
サンクス

2022/09/21(水) 06:25:52.07

includeガードって割と使われてるように思いますが、エラい人の批評とかありません？
依存関係を把握しきれてないヤバい状態の発覚を先延ばしにするだけのハックだと個人的な経験から思うのですが…

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-MXZj) · 2022/09/21(水) 06:39:05.65

とりあえず各ソースファイルの実行部、なければinit_xxxみたいなエントリーポイント作って
#ifdef XXX perror("xxx loaded twice"); exit(XXX);
みたいの置いたりしてます

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-MXZj) · 2022/09/21(水) 06:47:28.88

init_xxxを呼び忘れると無意味なので、文法エラーで落とせたら良いと思うんですが、分かりやすいメッセージ吐いて落ちてくれる違法構文(あるいはそうするときの標準的なイディオム)あったら教えて欲しいです

2022/09/21(水) 07:18:22.65

>>323
エロい人の批判ねえ。。。
#pragma onceなんか色んなコンパイラの中の人が真似してるけど？

依存関係を把握っていうけど、じゃあ
#include <stddef.h>
#include <stdio.h>
なんて書かされたいわけ？
ライブラリだって-lstdcじゃなく
fputc.o iobuf.o fprintf.o printf.oなんて書くべきだと思う？

何かを使いたいときの窓口を１つにまとめておくのは
作る側として行儀のいいことだと思うぞ

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-MXZj) · 2022/09/21(水) 07:47:36.87

>>326
むしろグッドプラクティスとされてる感じですか、確かにシステムヘッダにも見掛けますね

標準ライブラリは使うものを共通ヘッダにまとめてますね
ライブラリとして公開する場合は当然慣習に従うべきだと思いますが、書いてる時には丁度必要十分でなく、余計なヘッダがあると何処に何があったか混乱したりしません？

コードを弄らずスタティックアナライザとか道具に頼った方がいいのかな

2022/09/21(水) 09:18:02.72

>>323
ライブラリはそのライブラリの使用者に対して
インターフェイス部分だけを公開したいのが普通で、
細かい依存関係が見えてしまうのは悪い設計だろ。

でも C のヘッダファイルの仕組みは隠蔽しきれない部分が出てしまうので
そもそも C の言語としての仕組みが悪い。
C を使う以上は悪い部分ともつきあわないとしょうがないし、
インクルードガードは比較的マシな解決方法だと誰もが考えているからこそそうなってる。

C++ にはモジュールが導入されたけど今のところはヘッダファイルとも共存し続ける必要があるから
完全な移行にかかる時間は数十年単位かもしれんな……。

2022/09/21(水) 09:58:34.67

新言語作った方が早いw

2022/09/21(水) 18:18:19.49

>>327
>余計なヘッダがあると何処に何があったか混乱したり

へたくそなライブラリだとそういうの見掛けるが
上手なライブラリはすっきりしてるイメージ

2022/09/21(水) 18:19:32.68

>>328
FILE * とかって結局使う方からしたら void * でも動くしな

2022/09/21(水) 18:21:06.66

>>329
Nimがある

2022/09/22(木) 19:42:13.93

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <memory.h>

typedef struct {
int year;
int mon;
int mday;
int hour;
int min;
double high;
double open;
double close;
double low;
} CSV_T;

void f(CSV_T *csv){
CSV_T *work;

for(int i=1; i<1001; i++){　//★
work = realloc(csv, sizeof(CSV_T)*i);
if(work == NULL){
puts("error");
exit(0);
}
if(work != csv) {
puts("ココ通過でアウト");　//▲
csv = work;
}
}

2022/09/22(木) 19:42:52.92

csv[0].year = 1;
csv[0].low = 1.1;
csv[998].year = 9;
csv[998].low = 9.9;

printf("%d %f\n", csv[0].year, csv[0].low);
printf("%d %f\n", csv[998].year, csv[998].low);
}

void main(void){
CSV_T *csv;

csv = realloc(NULL, 1);
f(csv);

printf("%d %f\n", csv[0].year, csv[0].low);
printf("%d %f\n", csv[998].year, csv[998].low);

free(csv);
}

2022/09/22(木) 19:43:37.01

・やりたいこと
CSVファイルを１行読み込むごとに構造体のエリアをreallocで拡張して格納
元のソースをそのままアップするには長いのでファイルの読み込み部分を削除したソースが上のやつです

・悩んでいるところ
コメント★のとこのループが1000程度なら動きます。
しかし10000を超えるループにするとコメント▲部分を通過するようになり
mainのprintfが正しい値を表示しなくなります。

なぜ？

2022/09/22(木) 19:58:17.91

領域拡張がそのままでは出来ずに新たな領域に指定サイズで取り直すからでは？
どっちにしてもそんなに細かくrealloc()するものでは無いし
ある程度の大きさで取っておいて足りなくなったらrealloc()するのが本来の使い方

2022/09/22(木) 19:58:48.48

reallocが別のメモリを確保して返す場合
▲のほうを通ります
このときfの内部でcsvを変更しても
mainのcsvは変化しません。
返り値にするかfの引数をCSV_T**にするか
変更すればよいです。

2022/09/22(木) 21:54:30.38

>>293
昔はデータ容量を節約する必要があったから、データ容量が増えることは避けたかっただけ。

2022/09/22(木) 21:56:10.71

>>295
①や②を使っている時点で日本人の都合を世界に押し付けていることがわからないのか？

2022/09/22(木) 22:34:09.45

丸数字はUnicodeに登録されてるから心配ないよ
㋿ですら存在するし

2022/09/22(木) 23:15:55.13

>>293
そんなこと言ってたらUnicodeには肌色を指定する文字があって、これは通常表示されない
これらを組み合わせると家族絵文字はたった1文字を表示するのに最大で41byteになる
もはや文字を正しく表示する事は簡単じゃない
BOMの有無なんてかわいいもんだ

2022/09/22(木) 23:47:09.65

私が Unicode のグダグダさについて言いたいことは >>301 が全てなので繰り返しになるんだが
そもそも自然言語がグダグダなのが問題の根源。
文句があるなら自然言語を規格化して普及させてみせろや。

2022/09/22(木) 23:50:49.90

人それぞれなんだが、
自分が一番困るのは

　　～

これの扱いでいつもトラブル

2022/09/23(金) 00:53:58.54

「が」と「か゛」が混ざってる事もある(見た目じゃ判別付かない)から、先ずはUnicode正規化しないと、なぜか文字列が一致しないとかもある

2022/09/23(金) 01:35:24.44

>>335
>>333-334 で work を書き換えて csv に上書きしてるつもりで
main の csv は上書きされていない
f 側では CSV_T **csv で受けて *csv = work; と描いて上書きする
main から &csv を渡す

2022/09/23(金) 01:37:21.11

ここと
work = realloc(*csv, sizeof(CSV_T)*i);
ここも
if(work != *csv) {
変更汁

2022/09/23(金) 06:31:49.61

>>346
ここも直さんとエラーになるぞ
void f(CSV_T **csv){

2022/09/23(金) 08:25:09.61

>339
日本の都合に合わせたOSを作ったらアメリカから(ry

2022/09/23(金) 08:38:34.03

BOMはいるとかいらないとか
自分を中心に語っている間は自己中心的、なんじゃないですか？
BOMあったほうが良い環境と無いほうが良い環境があるなら、それに合わせて利用するでは？

2022/09/23(金) 08:55:36.44

>>349
いまはネットでつながってる時代なので、BOMを付けるべきでしょう。
自分だけで使う資料なら、何も言いません、自由にしてください。

2022/09/23(金) 09:05:36.75

>>336-347
動きました。
指摘頂いた箇所を直してコンパイルすると、コンパイラが
　error: ‘*csv’ is a pointer; did you mean to use ‘->’?
っと吐くので、コンパイルメッセージ通り
　csv[0]->year = 1;
　csv[0]->low = 1.1;
　csv[998]->year = 9;
　csv[998]->low = 9.9;
と修正したら　Segmentation fault (コアダンプ)　となるので随分悩みましたが
以下のようにすることで望む動作となりました。サンクスです。おわり。
　csv[0][0].year = 1;
　csv[0][0].low = 1.1;
　csv[0][998].year = 9;
　csv[0][998].low = 9.9;
　printf("%d %f\n", csv[0][0].year, csv[0][0].low);
　printf("%d %f\n", csv[0][998].year, csv[0][998].low);

2022/09/23(金) 10:00:54.82

>>348
そんな幻覚を信じてる奴がC言語使うなｗ

2022/09/23(金) 10:17:08.51

中国がやられていることを、以前は日本がやられていた。

2022/09/23(金) 10:36:16.17

中国のはただのLINUXもどきだろｗ

2022/09/23(金) 10:43:48.77

アメリカは許さん。
いつかアメリカが弱くなった時、必ず仕返しをする。

2022/09/23(金) 10:46:24.11

アメリカはほんとジャイアンだよな
色々な国から恨み買ってると思うわ

2022/09/23(金) 11:04:10.31

そういう下らない話はどっかの陰謀論スレでやれ
CもUNIXもパソコンもどこの国が作ったんだよｗ

2022/09/23(金) 11:14:08.38

だから国産のCやUNIXが必要なんだよ
アメリカにずっと依存してたらいつか痛い目を見ると思うわ

2022/09/23(金) 11:24:24.02

Cのどこに陰謀なんかあるんだよ
ちゃんと理解して使ってる人なら絶対にありえない妄想だな
いつまで経ってもHello worldの域を出られないウルトラ低脳だけだろそんなこと言ってるのは

2022/09/23(金) 12:04:08.03

ビジコンの小島社長が技術だけでなく、世界を目指していたら
今頃は世界を制覇して太ろうに

2022/09/23(金) 13:05:01.09

>>351
そこまで csv[0] 多用するなら
引数を void f(CSV_T **pcsv) にして
関数内で CSV_T *csv = *pcsv; すると良い
最後に *pcsv = work; だけ気を付ける

2022/09/23(金) 13:28:27.27

>>358
じゃあLINUXはどこの国の人が作った？
一行でもプログラム書いたことないのがバレバレだぞｗ
くだらねえ陰謀論書くヒマあったら

2022/09/23(金) 14:25:39.25

世界初のCPUは(ry

2022/09/23(金) 14:59:32.72

イギリス人のノイマンが考えてアメリカのEDVACに搭載されたのが最初だっけ

2022/09/23(金) 15:24:24.40

ジョン・フォン・ノイマンはハンガリー出身のアメリカの数学者。
両親はハンガリーに移住したユダヤ系ドイツ人。

2022/09/23(金) 16:25:05.41

>>362
五橋研究所の一件は絶対に忘れない。
アメリカを許さない。

2022/09/23(金) 17:04:19.95

>>363
何を以てCPUと呼ぶかという定義の違いによってどれが世界初のCPUかが変わる。

2022/09/23(金) 17:15:38.41

ノイマンは原爆は地上100mで爆発させるのが最もダメージを与えられるという計算を一生懸命してた人

2022/09/23(金) 17:59:34.63

技術が政府を必要なくするという妄想を主軸に据えた改定アナーキズムを提唱します。

国を細分化し、一つの国の力を十分に小さくすれば、戦争は消え去ります。
それも改定アナーキズムの効果のひとつです。

2022/09/23(金) 18:46:47.28

>>362
Linuxの開発はC言語依存だろ
そしてC言語はアメリカ産の言語
国産のC言語で国産のLinuxを作る
これが真の国力だよ