なんでもC言語で開発する奴アンチスレ (592ﾚｽ)
上下前次1-新
1(4): 仕様書無しさん [sage] 2020/12/13(日)09:07
リーダーの命令でC#、C++、Python、Java、Javascript、Kotlin等、OOPパラダイムを取り込んだ言語及びフレームワークを使った開発を封印して苦労しながら開発している人達のためのアンチスレです
493: 仕様書無しさん [] 2022/07/28(木)20:44
>>492
わざわざ中水準言語を使う必要がないという話だぞ。
494: 仕様書無しさん [sage] 2022/07/28(木)21:12
んなこと言い出したら今時のスクリプト言語でC言語処理系作る方がよっぽど楽な件
495: 仕様書無しさん [] 2022/07/28(木)22:47
同じものを作っている時点でやばいだろ
496: 仕様書無しさん [] 2022/07/29(金)08:03
まあ、STL使うぐらいならJavaやPythondで十分という考え方はアリだな。
だから当初から言ってるだろ、STL使わない縛りをまずはやれって。
497: 仕様書無しさん [sage] 2022/07/29(金)21:28
言語が低級かどうかは特定の機械語との対応で決まる相対的なものでしかない
x86上のCならローテーション等高度なビット演算や（使う機会があるかどうか別にすればBCD周りの命令）を欠いてるし、結構高級
lispはx86上では高級言語だけど、lisp マシン上ならlisp関数と機械語がほぼ同名で一対一対応する超低級言語、アセンブリそのものだ
498: 仕様書無しさん [] 2022/07/29(金)22:46
いまどき実行速度の話にもっていく人間がいるとは思わなかった
499: 仕様書無しさん [sage] 2022/07/31(日)09:00
>>491
今回限りの処理で、オブジェクトが一つだけの場合はそれになりやすい…
別の名前にできる場合は別の名前でやるけど
これでも向いてないのか…？
500: 仕様書無しさん [] 2022/07/31(日)09:18
だから言ってるだろ、Cなんてシロウトには無理って。
無理なんだから無理はするな。 素直に出来るやつに任せて、
お前らは出来るやつのために仕事取る営業に専念しろ。
501: 仕様書無しさん [sage] 2022/08/26(金)14:54
>>492
んなこたあない
502: 仕様書無しさん [sage] 2023/06/10(土)19:52
この板、C言語おじさん多すぎないか？
定期的に戒めでこのスレタイageたくなる
503: 仕様書無しさん [sage] 2023/06/29(木)21:07
組み込みはCだからね
メーカー系にいっぱい組み込みおじさんがおる
504: 仕様書無しさん [sage] 2023/09/13(水)22:14
失敗しなくちゃ成功はしない
505: 仕様書無しさん [sage] 2023/12/16(土)20:49
C++といいながら丸々Cじゃねーかってのはよくあるな
506: 仕様書無しさん [] 2024/03/29(金)15:20
兼オタなんて出来ないでよｗｗ
507: 仕様書無しさん [sage] 2024/03/29(金)15:31
シーズン
8月17日
508: 仕様書無しさん [sage] 2024/03/29(金)16:12
阿呆おるんか
509: 仕様書無しさん [] 2024/03/29(金)16:24
運動で信者を炙り出して、人生で最大の謎の上から目線で言い、信者名）の確保も必要だし制作側にとってははた迷惑な話だぞ
あと炭水化物があまりに不正利用について可能性あるな
改ざんしてるに決まってるじゃん！
510: 仕様書無しさん [] 2024/04/19(金)05:28
すでにあるものの組み合わせでできるのに一から作るやつはヤバい
511: 仕様書無しさん [sage] 2024/05/04(土)17:26
Cはポインタのお遊びに使えるけど、あまり実用的ではない
権威ある大学教授がCを学ぶ人は負け組だの底辺層だの散々学生に刷り込んでいるから、若手でやる人は減ってきている
512(1): 仕様書無しさん [] 2024/05/04(土)18:09
米ホワイトハウス、開発者にRustなどメモリの安全性考慮した言語への移行促す
https://news.mynavi.jp/techplus/article/20240227-2893479/
脆弱性の特徴を持ち普及率が高い言語として、CおよびC++を挙げている。
このような脆弱性を軽減するために、「はじめからメモリ安全なプログラミング言語」の使用を推奨している。
レポートでは、その具体例としてCおよびC++を「Rust」へ移行することを促している。
513: 仕様書無しさん [] 2024/05/04(土)22:26
>>512
悪質なWebサイトだな
514(1): 仕様書無しさん [] 2024/05/04(土)23:11
「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html
515: 仕様書無しさん [sage] 2024/05/06(月)17:32
教育機関からC言語は今後使うなと言われているけど
だから、若者でC言語使う人が少ないのは当たり前
516: 仕様書無しさん [] 2024/05/06(月)18:13
米政府もIT大手もRustへ舵を切ったからしょうがない
517: 仕様書無しさん [] 2024/05/06(月)20:41
OSレベル、CPUレベルで分離されているんだけどな。
自分自身で自分をぶっ壊す危険があるという理屈なら、アメリカは銃の所持をやめないと理屈がおかしい。
518(1): 仕様書無しさん [] 2024/05/07(火)12:28
C/C++はこれまで大量のセキュリティホールなどの実害を招き続けてきたが
ガベージコレクションがなく高速に動作するプログラミング言語が他にないためC/C++は必要悪であった
しかし同じ速さで動作して安全なRustの登場によりC/C++を捨てることができるようになった
519(1): 仕様書無しさん [] 2024/05/12(日)02:04
>>518
知識がないのがバレているぞ？
メモリの管理がずさんなダメプログラマーの問題をプログラミング言語の話と解釈しているのは無知すぎる
520: 仕様書無しさん [] 2024/05/12(日)14:00
>>519
そのプロがミスをしまくってセキュリティホールの問題が深刻なので
米政府もIT大手も脱C/C++を推奨し始めたのが>>514の記事
521: 仕様書無しさん [sage] 2024/05/12(日)18:20
大手エージェントの担当者も低スキルの人がやる言語だとC言語のことをバカにしていた
522: 仕様書無しさん [sage] 2024/11/13(水)21:37
GUIを作るのが面倒
523: 仕様書無しさん [sage] 2024/11/14(木)12:35
米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html
524: 仕様書無しさん [] 2024/12/04(水)22:52
EchoAPIはAPIの問題を迅速にデバッグするのに役立ち、安心して次に進むことができるよ
525: 仕様書無しさん [] 10/02(木)09:06
【貧困】稼げないSEを退治しろ【非婚】
☆高負担で低速度で低生産だろ！☆
★文書でなく会話で作業をしろ！★
プログラマー作業を減らして
オペレーター作業を増やすな！
低技術で低収入は高技術で高収入の
技術者に迷惑だからIT業界から失せろ！
526(1): 仕様書無しさん [] 10/12(日)02:14
attributeが正式にも分かりやすいsyntaxで、厳密な意味論、あるいはアノテーションを提供する機構として付いたことで、それらをしっかり活用している限りにおいて可読性が素晴らしく分かりやすくなったろう
restrictや配列/ポインタパラメータのstatic指定等も合わせて、今までのコメントのうち半分くらいは削れるようになったのではないかと感じる
出来れば先駆者のFortranにならって、より分かりやすいpure, elemental, in/out等による指定方式の方が直感的になったのでは…とは思うものの
そのへんのコンパイラの警告レベル上げまくればかなりセキュアに書けるだろ？
何でもとは言わんが少なくとも、cの敬遠されてきた原因、あるいは欠陥とされてきたであろう、仕様に暗黙なアレコレはほぼ排除されたのでは
c23を信じろ
527(3): (u _ ・ｙ) r [] 10/15(水)02:58
(u _ ・ｙ) r メモリーを安全にさせるってことは
(u _ ・ｙ) r 少なくとも動的確保したときにアドレスのメモが裏で発生するわけで
(u _ ・ｙ) r どう足掻いても1クロック遅くなってしまう模様
(u _ ・ｙ) r １クロック妥協するなら５０クロック妥協して高級言語使ってろよ（ｗ
528(2): 仕様書無しさん [] 10/15(水)10:38
>>527
アドレスのメモ？
1クロック遅くなる？
デタラメ言うなよ
529(2): 仕様書無しさん [sage] 10/15(水)14:23
1命令実行するだけでも数クロックかかるよね
例え変数がレジスタに存在していても
530: 仕様書無しさん [sage] 10/15(水)14:52
命令ごとのクロック数はIntelのマニュアルに書いてあるよ
531: 仕様書無しさん [] 10/16(木)01:39
>>529
それは理由になっていない
どういう理由でどんな命令が増えるから遅くなるのかを答えなさい
532: 仕様書無しさん [sage] 10/16(木)02:26
メモリからのロード待ちでCPU暇してるかも知れんよ
533: 仕様書無しさん [] 10/16(木)02:42
C言語スレは低レイヤーで語ってるのとプログラム1年生が入り乱れてるからわけわからんな
534(3): 仕様書無しさん [] 10/16(木)04:39
>>527
安全にするためになぜ1クロック遅くなる？
>>529
何らか命令が増えればそうだよ
安全にするためになぜ1クロック遅くなるのる
なにか命令が増えるとでも？
535: 仕様書無しさん [] 10/16(木)07:14
チェチェン語で
536: 仕様書無しさん [] 10/16(木)08:50
>>534
ガベコレ含めてハードやカーネル階層に全部放り投げられる手段があればプロセス階層でのメモリー制御の処理は1クロックも増えないかもしれんが
そういうのあんのか？
537(2): (u _ ・ｙ) r [] 10/16(木)09:25
✅ 原文の解釈と意図： >>527
(u _ ・ｙ) r メモリーを安全にさせるってことは
→ メモリの安全性を確保する（例：バッファオーバーフロー防止やアクセス違反を防ぐ）というのは、
(u _ ・ｙ) r 少なくとも動的確保したときにアドレスのメモが裏で発生するわけで
→ 動的にメモリを確保したときには、内部でそのメモリの「どこにあるか（アドレス）」を記録・管理する処理が裏で発生する。
（つまり安全のためには追加の処理が必要になる）
(u _ ・ｙ) r どう足掻いても1クロック遅くなってしまう模様
→ どんなに頑張っても、結局その安全処理のせいで最低でも1クロック（CPUの命令処理1単位）遅れてしまう。
(u _ ・ｙ) r １クロック妥協するなら５０クロック妥協して高級言語使ってろよ（ｗ
→ 皮肉。「たかが1クロックの遅れで文句言うなら、いっそ50クロックくらい妥協して高級言語（C++、Java、Pythonなど）でも使ってろよ（笑）」
つまり、「中途半端にこだわるくらいなら、いっそ諦めて楽な道を選べば？」という煽りっぽいコメント。
538(1): (u _ ・ｙ) r [] 10/16(木)09:26
✅ なぜメモリの安全性を高めるとパフォーマンスが落ちるのか？
1. 追加のチェックが必要になる
たとえば、次のようなチェックが行われるようになります：
範囲外アクセスの検出（バッファオーバーラン防止）
ヌルポインタチェック
メモリの二重解放防止
所有権・ライフタイムの管理
➡ これらのチェックは、CPUにとっては余計な処理であり、時間がかかります。
2. 抽象化が入る
安全性の高い言語（Rust、Java、Pythonなど）は、直接ポインタ操作を許さず、間接的にしかメモリを扱わせません。
安全だけど、抽象化のオーバーヘッド（遅くなる）が発生
3. 動的管理のコスト
メモリの割り当てと解放を安全に管理するために、次のような処理が必要になります：
ヒープアロケータの内部構造の更新
スレッドセーフなロック処理
メモリリーク検出の仕組み
➡ これもまた、処理の遅延につながります。
結論：本質は「安全性＝タダではない」
Yes：安全性を高めると、一般にはオーバーヘッド（遅延）が発生する
But：その遅延は技術で最小化できることも多く、「妥協」と言い切れない
539: 仕様書無しさん [sage] 10/16(木)13:57
今のintel cpuはメモリからレジスタにロードするだけで300クロックかかるんじゃなかったか?
540: 仕様書無しさん [] 10/16(木)14:19
話にならん遅さだな
541: 仕様書無しさん [sage] 10/16(木)14:32
キャッシュヒット率が重要だ
542: (u _ ・ｙ) r 結論：本質は「安全性＝タダではない」 [] 10/17(金)04:43
(u _ ・ｙ) r >>528 , >>534
反論マダー？
543: 仕様書無しさん [] 10/17(金)04:50
キャッシュ当選率を語るならばなおさら短いコード生成が重要だ
>>526
いぇあ、Cはこのスレで叩かれてる部分がめさにドンドン良くなってる
C99おじさんは死ね
544(1): 仕様書無しさん [] 10/17(金)07:03
>>537
安全のため必要なアドレスのメモってなんだよ
意味不明だからメモという存在しない現象を使わずにやり直したまえ
545: (u _ ・ｙ) r [sage] 10/17(金)09:17 AAS
AA省
546: (u _ ・ｙ) r [] 10/17(金)10:01 AAS
AA省
547(1): 仕様書無しさん [] 10/18(土)01:06
>>537
根本的に理解的できていないようで間違ってるぞ
✕ 動的にメモリを確保した時にメモリ安全性のためにそのアドレスを記録する必要がある
○ 動的にメモリを確保した時に常にそのアドレスを記録する必要がある
548(1): (u _ ・ｙ) r [] 10/18(土)05:57
>>547
逃げずに答えろよ
アドレスを記録しているのは「カーネル」か「プロセス」か
549: (u _ ・ｙ) r [] 10/18(土)06:03
(u _ ・ｙ) r 基礎を学んでいないと薄ぼんやりとした解像度の低いレスバしかできない人になる 恥ずかしい
550: 仕様書無しさん [sage] 10/18(土)20:14
malloc(unix system call)・malloc(libc)
GlobalAlloc/LocalAlloc(winapi)・HeapAlloc(winapi)・VirtualAlloc(winapi)・malloc(msvcrt)
×
Intel MAT・Intel SLAT
×
CPU register・L1〜L3 cache
さて、あなたのデータはいずこに！？
551(1): 仕様書無しさん [] 10/19(日)01:50
>>548
君はOSの仮想メモリ管理も各プロセスでのヒープメモリ管理も理解できていないからそんな意味不明な書き込みになる
552: (u _ ・ｙ) r [] 10/19(日)17:47 AAS
AA省
553: (u _ ・ｙ) r [sage] 10/19(日)17:53
この話のポイントは「安全性＝タダではない」>>538
JAVAのように中途半端に遅い言語は一番いらない子になったNA
藁・ｘ・
ｗ(u _ ・ｙ)
554: 仕様書無しさん [] 10/20(月)01:10
安全のために追加コストは必要ない
555: (u _ ・ｙ) r [] 10/20(月)04:34
(u _ ・ｙ) r 道路で考えてみよう
(u _ ・ｙ) r 現実世界では車道と歩道を分けて交通トランザクションを処理しているけど
(u _ ・ｙ) r 車道と歩道を分けるコストは0だというのかね？
(u _ ・ｙ) r 車道を走る車、歩道を歩く人、これらをコンピュータにおいてアドレスからアドレスへ移動中のデータとして考えよう
556: 仕様書無しさん [] 10/24(金)09:41
【貧困】稼げないSEを退治しろ【非婚】
☆高負担で低速度で低生産だろ！☆
★文書でなく会話で作業をしろ！★
プログラマー作業を減らして
オペレーター作業を増やすな！
低技術で低収入は高技術で高収入の
技術者に迷惑だからIT業界から失せろ！
https://listen.style/p/readmaster/mcqg3wwz
557: (u _ ・ｙ) r [] 10/24(金)13:42
(u _ ・ｙ) r やっぱＣ言語ですわ
(u _ ・ｙ) r 難しい箇所が書けないとか甘え
558: 仕様書無しさん [] 10/25(土)01:21
欠陥C言語を使い続けるには知識と覚悟が必要
559: 仕様書無しさん [sage] 10/25(土)14:32
C言語は別にいいんだよ
高級マクロアセンブラという重要な役割がある
問題はC++
こいつはもうめちゃくちゃだ
560: (u _ ・ｙ) r [sage] 10/26(日)06:16
(u _ ・ｙ) r C++は標準仕様と拡張仕様にすべきものの分離に失敗したからな
(u _ ・ｙ) r 技術的・構造的な限界までは言語仕様拡張じゃなくって
(u _ ・ｙ) r 元の言語使用のままライブラリで拡張するって形にしないといけないのに迷走し
(u _ ・ｙ) r その結果、ただの#defineマクロでも可能だったものをC++独自構文でメタプログラミングし始めて余計複雑に
(u _ ・ｙ) r C++のマクロは限界まで#defineで実装し、それで出来ないものに関してのみ言語仕様に入れるべきだった
561: 仕様書無しさん [] 10/26(日)11:31
C/C++の後継のRustが出来たから
IT企業はRustへ移行していってるね
562: 仕様書無しさん [sage] 10/26(日)14:59
RustはC系にくらべたら遅いと聞いたが
563: 仕様書無しさん [sage] 10/26(日)17:00
速くはなかなかならんでしょ
564: 仕様書無しさん [sage] 10/26(日)17:03
セキュリティコストと速度のコストのトレードオフはユーザーが考えるんや
公開サービスなどでセキュリティが重要ならRustはあり
ラボで数値計算に使うならCでもFORTRANでも好きなの使っとき
565: 仕様書無しさん [sage] 10/26(日)19:59
命にかかわる絶対的セキュリティや正確さが必要な場面なら
それでも使われない
使えない
オブジェクト志向は凡人向け
566: 仕様書無しさん [sage] 10/26(日)20:35
Rustは別にオブジェクト指向じゃないよ
開発者の頭次第だ精進するしか
567(3): 仕様書無しさん [sage] 10/26(日)20:50
命にかかわるシステムにはジャンプ先を動的に指定するものは使えないと聞いた
オブジェクト指向はほぼ全てのメソッド呼び出しがそうなので使えない
Rustもオブジェクト志向でなくてもトレイトがある以上同じこと
568: 仕様書無しさん [sage] 10/26(日)21:16
なるほどアセンブリ
569: 仕様書無しさん [] 10/27(月)07:56
>>567
つまり副作用があっちゃいけないとかいう話だろ
理想論としてはそれでいいけど日本の開発ってほんとにそんなレベルでセキュリティ確保できてんかな
570: 仕様書無しさん [] 10/27(月)08:21
>>567
Rustのメソッド呼び出しは静的に確定することができるため問題なし
『単相化 Rust』で検索してごらん
571(1): 仕様書無しさん [sage] 10/27(月)08:59
そんなのは別にどんな言語でもできるだろ
問題は言語使用上、その言語を使っている限りは不可能です
って断言ができて抜け道がほぼ無い事が確証されていることで
納品先に安心感を与えて売り込む みたいな話だと思うよ
572: 仕様書無しさん [] 10/27(月)09:09
C/C++は失格だからそんな言語がないんじゃない？
573(1): 仕様書無しさん [] 10/27(月)09:10
>>571
単相化できるのはC++とRustだけだよ
574(1): 仕様書無しさん [sage] 10/27(月)16:22
それらが出来るならアセンブリとCも出来るやろ
575: 仕様書無しさん [sage] 10/27(月)16:24
リフレクション使わなければいいだけだったりしないか
576: 仕様書無しさん [sage] 10/27(月)17:35
えっ
577(1): 仕様書無しさん [] 10/27(月)22:43
>>574
C言語は能力が低すぎて単相化はできません
578: 仕様書無しさん [sage] 10/27(月)22:51
アセンブラ上の型式チェックができんのじゃないかのう
もちろん関わったことなんかないから知らんけど
579: 仕様書無しさん [sage] 10/28(火)01:04
>>577
そしたら命に関わるシステムはどうするのよ。単相化より原始的にやれてるんだろう
580: 仕様書無しさん [sage] 10/28(火)01:08
ジェネリックスがないC言語では単相化など不要
もともと全てが単相なのだ
581(2): 仕様書無しさん [sage] 10/28(火)04:41
>>567
>>命にかかわるシステムにはジャンプ先を動的に指定するものは使えないと聞いた
>>オブジェクト指向はほぼ全てのメソッド呼び出しがそうなので使えない
メソッド呼び出しの実現方法は以下の3つに分類される
①単相化 … 各型毎に別コードにするためコンパイル時にジャンプ先が確定
②固定vtable … コンパイル時にvtableが確定し実行時に各型に対応する固定ジャンプ先へ
③可変vtable … 実行時にジャンプ先を追加したり変更したりできる
このうち③が危険
582: 仕様書無しさん [sage] 10/28(火)04:44
そう言えばJavaインストールする時に免責同意求められるね。命に関わることには使わないでね。って
583: 仕様書無しさん [sage] 10/28(火)04:46
Cにvtableないからね。関数ポインタ禁止すれば達成される
584: 仕様書無しさん [] 10/28(火)06:05
>>581
Rustは①と②だけなので安全とみなされ採用されている
585: 仕様書無しさん [] 10/28(火)06:21
>>573
お前はな（ｯﾌﾟｗ
586: 仕様書無しさん [sage] 10/28(火)07:49
C言語は原始的な機能しかないがゆえに"自分で作れてしまう"からな
587: 仕様書無しさん [sage] 10/28(火)12:31
vtable的なものは自作するね
使いすぎも注意とはちょっと勉強になった
588(1): 仕様書無しさん [] 10/29(水)07:57
C言語でも>>581の③を避ければその問題はクリアできるけど
それ以外に普通に落とし穴が多すぎてセキュリティホールを多く産み出してきた
589: 仕様書無しさん [sage] 10/29(水)10:26
穴の中に穴を作った
590: 仕様書無しさん [sage] 10/29(水)16:13
何を作るにしてもフレームワークを調べて、オープンソースを調べて、AIに作らせて・・・
自分で何もつくれないなんてプログラマになった意味がない
591: 仕様書無しさん [sage] 10/29(水)23:25
早く作れて楽しくないか。コンポーネント設計みたいなのAI上手いんだよね。
自分でやる同等以上で助かる。というか師匠
592: 仕様書無しさん [sage] 10/29(水)23:26
>>588
後半が大問題よね。Rust使える技能と環境があるならRustがいいよ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.109s*