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