なんでもC言語で開発する奴アンチスレ
- 1 :仕様書無しさん:2020/12/13(日) 09:07:28.51 .net
- リーダーの命令でC#、C++、Python、Java、Javascript、Kotlin等、OOPパラダイムを取り込んだ言語及びフレームワークを使った開発を封印して苦労しながら開発している人達のためのアンチスレです
- 412 :仕様書無しさん:2021/03/08(月) 15:41:15.05 .net
- C programming language
- 413 :仕様書無しさん:2021/03/08(月) 15:53:54.49 .net
- そうだCPLと呼ぼう!
- 414 :仕様書無しさん:2021/03/10(水) 08:01:15.28 .net
- PL/Cが好み
- 415 :仕様書無しさん:2021/03/27(土) 21:48:43.05 .net
- Cで検索するだけで上から二番目がC言語だったぞ
ちょっと「練」が足りないんじゃないか
- 416 :仕様書無しさん:2021/04/06(火) 19:48:13.15 .net
- .NET開発はVBかC#、どっちかに統一しろよと思う
- 417 :仕様書無しさん:2021/04/08(木) 18:23:09.11 .net
- 書き途中
>>414
pl/1思い出した…
まだ残ってるのかな…
- 418 :仕様書無しさん:2021/04/28(水) 21:30:38.21 .net
- >>416
吐き出す中間コードは同じだと聞いたが?
- 419 :仕様書無しさん:2021/08/06(金) 21:18:25.75 .net
- >>4
C++すらって…
C++が一番難しい気がする…
- 420 :仕様書無しさん:2021/08/07(土) 05:16:22.69 .net
- C++の難しさは
後から後からその場しのぎに拡張して来たことによる複雑さと「わかりにくさ」
そしてそれらを完璧に理解して使いこなしていても
複雑な込み入ったプログラムではどうしても主にメモリ関連のバグ(ミス)が生じてしまっている現状
だから有能な人ほどRust導入を検討もしくは導入しているし大手IT企業はRustを採用しようとしているか既に採用している
- 421 :仕様書無しさん:2021/08/07(土) 05:33:18.26 .net
- そりゃあ企業単位でC++で開発するのはもう無理だよ。
できる奴確保できないもん。
最初に言ったように、能無しをうっかり雇うのを防ぐという目的なわけだが、
そのふるいをかけて人材確保に成功するかどうかは、あくまでも別の話だからね。
- 422 :仕様書無しさん:2021/08/07(土) 05:54:46.25 .net
- >>420
言語の優秀さの差で勝負ついたね
新規プロジェクトはC++捨ててRustだらけ
- 423 :仕様書無しさん:2021/08/08(日) 03:59:10.49 .net
- C++使いの人に質問
これは10年前の記事からの抜粋だけどいまでは解決されてるの?
・STL のアロケータは極めて扱いづらいく、コードの肥大化を招き、効率も最適ではない。
・いくつかの STL の実装には slist, hash_map, shared_ptr などの有用なものが用意されているが、これらはポータブルではない。用意されてない実装もあるし、バージョンの違いで互換性がなかったりもする。
・STL は関数呼び出しの階層が深く、それによりインライン化が妨げられ、遅くなっている。
・STL は非常にデバッグしづらい。例えば std::list は void* を使うためにデバッガで内容を見れないことがある。また、暗号めいた変数名やデータ構造だらけな上、コードに関するドキュメントがない。
・STL のコンテナは、格納するオブジェクトのアライメントをサポートしていない。アライメントに関するサポートが弱いのは C++ の欠点である。アライメントに関するサポートは C++09 で提案されている。
・STL のコンテナは、要素を追加するときにコピー渡しする必要がある。これはコンストラクタのコストが高いオブジェクトで非効率的である。
・STL コンテナは private な実装を持ち、データ構造などをポータブルには弄れないようになっている。これができることが重要な場合もある (node pool など)。
・STL の多くの現在の実装が、空のコンテナにメモリを割り当てることがある。これは最適化を妨げており、効率改善の大きな余地がある。空のコンテナはメモリを割り当てるべきではない。
・STL のアルゴリズムの全ての実装は述語の参照をサポートしておらず、それが原因で非効率的なハックを強いられることがある。
・STL は実用性、効率より正当性に重点を置いている。これは妥当なポリシーだが、std::allocator など、いくつかのケースではユーザビリティと効率を妨げている。
- 424 :仕様書無しさん:2021/08/08(日) 05:09:00.67 .net
- ホントに最適化が必要なら自力で高速コンテナ作るよ
べつにすべてが最適化されている必要はないし最適化されていないと夜も寝れないビョウキなのか
- 425 :仕様書無しさん:2021/08/08(日) 05:13:19.77 .net
- どちらかというと自分が書いたコードの動きが詠めずにコンパイルエラーに頼りまくるやり方の方が大問題な気がする
- 426 :仕様書無しさん:2021/08/08(日) 05:16:10.35 .net
- コンパイルエラーが難しくて解りにくいってコード書いてエラー出しているのは自分なんだから少し考えればどうしてそうなったか判るだろ普通は
- 427 :仕様書無しさん:2021/08/08(日) 05:35:37.94 .net
- 新たな案件だとバックエンドから組み込みまであらゆる分野で、C++捨ててRustにする例が増えているから、C++は既存の案件メンテ用の地位に落ちた。
- 428 :仕様書無しさん:2021/08/08(日) 10:29:53.95 .net
- >あらゆる分野で、C++捨ててRustにする
だったら良かったけど、まだまだC++な部分が多いしなぁ
>C++は既存の案件メンテ用
にまで行くには、まだあと5年10年かかるコースでしょ
- 429 :仕様書無しさん:2021/08/08(日) 18:17:26.04 .net
- >>424
最適化されないと夜も寝れないビョウキな人はいる
ゲーム機向けに開発している連中は病的なほどに最適化にこだわる
この記事は米EA社(Apex Legendsとか作ってる会社)が書いたもの
STLはゲーム開発に適さないのでEASTLという自社ライブラリを作成して使った
というのが10年前のはなしなんだけど、10年経って状況は変わったのだろうか?
- 430 :仕様書無しさん:2021/08/08(日) 19:29:42.71 .net
- 規格レベルの話と実装レベルの話が混在しててなぁ
少なくとも規格レベルの話はざっと見ただけでも解決されてるものは多い
std::unordered_map / std::unique_ptr / std::shared_ptr の標準入り(C++11) とか要素の直接構築, ムーブ挿入 (C++11) とか
- 431 :仕様書無しさん:2021/08/09(月) 01:58:40.73 .net
- そうか、C++も日々改良されて使いやすくなっているんですね
- 432 :仕様書無しさん:2021/08/09(月) 04:49:30.14 .net
- C++より便利かつ安全なRustが登場したことで徐々に置き換わっていきそうですね
- 433 :仕様書無しさん:2021/08/09(月) 14:58:24.85 .net
- ゲーム開発の現場ではそろそろC++では難しくなっているのかもしれない
その理由の一つがビルド時間である
ハードのスペックが年々上がり、それにともないゲームも複雑化している
昔は1対1だった対戦ゲームがいまでは100人バトロワである
カプコンはモンスターハンターRISEでC++をやめてC#を採用した
結果ビルド時間が1/100になったそうである
https://www.nintendolife.com/news/2021/06/feature_monster_hunter_rise_director_talks_re_engine_on_switch
その面でRustはC++の代替候補にはなりえない
RustもC++並にビルド時間を要するのだから
- 434 :仕様書無しさん:2021/08/09(月) 15:09:56.10 .net
- >>433
その論だとC#の代替にはならないだけで
C++並みなのだから、C++の代替にはなるだろ
- 435 :仕様書無しさん:2021/09/05(日) 01:20:06.59 .net
- なんでもKotlinとswiftで作ってごめんなさい
C♯とかDartとかC++は無理でございます
- 436 :仕様書無しさん:2022/02/05(土) 10:31:17.86 .net
- 業務系のプログラム作ってて、ラムダ式やテンプレート知らなくて困ったことが1度もない。
- 437 :仕様書無しさん:2022/02/05(土) 11:01:34.58 .net
- まあ、同じレベルの人間が集まりやすいからな
- 438 :仕様書無しさん:2022/02/05(土) 11:06:07.26 .net
- >>436
ラムダ式ってsort関数みたいなやつに渡す一回限りの処理をぱっと作るためのやつでは?(細かく言えば違うけど)
確かに使わんでも組めるけど使えるのなら実装が楽になる
- 439 :仕様書無しさん:2022/02/22(火) 22:03:31.86 .net
- ビット一つが重要な意味を持つハードウェア制御とかにゃCが向いてるよな、軽いし
- 440 :仕様書無しさん:2022/02/25(金) 02:21:33.10 .net
- 一回限りといえば一回限りだが、ループぶん回して何百もバリエーションを量産して、それを何百回も使って初めて意義があるので、使い捨てになるのは結果論でしかない
大体無名なのは、そういう使い方では名前なんて一々付けてられないし、その必要がないからで
無名なのも結果論
- 441 :仕様書無しさん:2022/02/25(金) 02:30:06.79 .net
- 名前を必要とするという仕様はいわゆるarbitrary limitationだよな
名前を付けたければ付ければいいんだし、コンパイル時にはどうせシンボル名は適当な識別子を割り当てられるんだから
- 442 :仕様書無しさん:2022/02/25(金) 02:41:53.85 .net
- >>483のように、無数のバリエーション必要としない、本当に使い捨ての関数を一回限り定義する為に無名関数を使うのは明らかにバッドプラクティス
名前を付ける事が可能であるかぎりは付けるべき
一つ一つの関数に名前を付ける事が現実的に不可能であるケースにのみ使用すべき
- 443 :仕様書無しさん:2022/04/15(金) 04:42:23.40 .net
- >>436
それは高階関数を引数とするメソッドが多い現代的なプログラミング言語を使ったことがない初心者なだけでは
- 444 :仕様書無しさん:2022/04/15(金) 10:56:14.55 .net
- メンテナンス考えたら本当に同じ役務にしか使い回しはしたらダメだしなぁ
基本関数以外に同じにしていい関数なんてほぼ無いんだよなぁ
- 445 :仕様書無しさん:2022/04/15(金) 21:55:41.73 .net
- Rustいいよぉ
Rust使おう
- 446 :仕様書無しさん:2022/04/18(月) 09:46:57.62 .net
- >>442
ほとんどの言語では無名関数(ラムダ式)を変数に入れることができて変数名が付くので全く問題ない
そして何でも通常の名前のある関数にしてしまうのは名前汚染で邪魔
もちろん高階引数を取るsort, map, filter類などに渡す時は名前すら必要なく無名関数(ラムダ式)のまま渡せたほうがメリット多い
- 447 :進撃のコンパイラ:2022/04/19(火) 00:37:37.13 .net
- Cを笑うものはCに泣く
この世の9割はCで出来ているのだから
- 448 :仕様書無しさん:2022/04/24(日) 00:13:23.56 .net
- 自分「組込でCを10年以上使ってます」
敵「じゃあC++でもC#でもJavaでも何でも応用効くよね」
無茶言うなや
10年もそれだけやってたら今更簡単には他の言語に移れんわ
- 449 :仕様書無しさん:2022/04/24(日) 08:17:00.21 .net
- CしかやってなかったらC++でさえ厳しいのにね
C#なんてむしろJavaとかやってなかったら多分Cからの移行は結構しんどいかも
オブジェクト指向というかクラス的な考えを中々理解出来ない人も多いようだし
- 450 :仕様書無しさん:2022/04/25(月) 09:28:35.98 .net
- C++のテンプレート
C#のデリゲートやラムダ式
いまだに使いこなせないわ
- 451 :仕様書無しさん:2022/04/26(火) 23:57:53.74 .net
- C++のテンプレートはコンパイル時に処理される別の言語だと思った方がいい気がする
デリゲートやラムダ式は使いこなすのに修練が必要な類のものでもない
- 452 :仕様書無しさん:2022/04/27(水) 11:22:14.57 .net
- デリゲートをラムダ式で書くとかさ、
まあ、むしろ追うの一箇所で済むからいいけど
- 453 :仕様書無しさん:2022/05/09(月) 07:26:10.89 .net
- Cは開発当時は完成度が高い最強の言語だったと思うよ
俺もCでプログラム覚えたし
でも今は流石にね
- 454 :仕様書無しさん:2022/05/10(火) 21:19:36.49 .net
- 今はCの代わりにRust
言語機能の利便性と安全性が段違い
- 455 :仕様書無しさん:2022/05/11(水) 01:00:37.68 .net
- 言語の見た目が目にうるさい
- 456 :仕様書無しさん:2022/05/12(木) 00:54:44.07 .net
- bufに詰めて返すAPIが分かりにくすぎる、サブルーチンなのか関数なのか、呼び方の文法だけ改善してほしい
Fortranみたいにせめて文法的に分けるとか
func()
call subr()
- 457 :仕様書無しさん:2022/05/12(木) 00:59:15.58 .net
- intent指定ができずaliasingの問題で最適化が妨げられてるし、そういうところでハイパフォーマンス言語としても中途半端でFortranに後塵を拝したわけで
- 458 :仕様書無しさん:2022/05/13(金) 01:54:56 .net
- ぜんぶ初耳だがどういうこっちゃ
- 459 :仕様書無しさん:2022/05/13(金) 11:21:11.28 .net
- なんでもFortranで書くやつなんて居ないから無害じゃね
- 460 :仕様書無しさん:2022/05/13(金) 12:03:57.89 .net
- 個人向けのCOBOL処理系とかあるんだろうか
- 461 :仕様書無しさん:2022/05/13(金) 14:23:03.73 .net
- 何でも重たい関数呼び出しにしてしまったツケは、まあ地道にinlineすればある程度埋められるだろ
- 462 :仕様書無しさん:2022/05/14(土) 00:57:30.62 .net
- opencobolというのがある
cobolの正反対の立場にいた
gnuが提供していることが
歴史の皮肉だな
- 463 :仕様書無しさん:2022/06/04(土) 23:23:09.04 .net
- やっぱFortranしか勝たん()
- 464 :仕様書無しさん:2022/06/25(土) 17:28:07.42 .net
- おれの国のほうが
- 465 :仕様書無しさん:2022/07/06(水) 23:54:41.45 .net
- 久しぶりにこのスレを見るのだが、Cは必須厨のハケンジジーが、
なんと、Cの組み込み案件に携わることになってしまった。
- 466 :仕様書無しさん:2022/07/12(火) 23:32:16.87 .net
- なんでもC言語で書くのはあまり見たこと無いけど、なんでもC言語(の書き方)で書く人は結構見てきている
お前今書いてるのC++/C#だぞCじゃねぇんだぞって何度思ったことか。おっさんや組み込み出身者は大体そう
- 467 :仕様書無しさん:2022/07/13(水) 09:14:08.87 .net
- >>466
例えば?
クラスにせずに全てC#でいうstaticなメソッドとか?
- 468 :仕様書無しさん:2022/07/13(水) 09:36:39 .net
- C++とC#なんて全く違うのに同じ括りで語るとか
C++ならまだCっぽく書けるがC#なんて無理だろ
- 469 :仕様書無しさん:2022/07/13(水) 15:22:38.08 .net
- >>466
Cの汎用性の高さが証明されたな
ちゃんと動くならどんな書き方でも良くね?
- 470 :仕様書無しさん:2022/07/13(水) 16:03:49.80 .net
- objectiveC !
- 471 :仕様書無しさん:2022/07/13(水) 19:31:03.91 .net
- ん?
a << bで済むのが、わざわざstrcatつかってるとか?
- 472 :仕様書無しさん:2022/07/13(水) 21:27:32.42 .net
- C言語なんて勉強していたらコロナ禍でリモートワーク率0%の現場に派遣される
キャリアサポートセンターの人もC言語は学ばない方がいいとセミナーで話していた
- 473 :仕様書無しさん:2022/07/13(水) 21:32:55.78 .net
- リモートワークの現場なんてスグにクビになるからねぇ。
- 474 :仕様書無しさん:2022/07/16(土) 18:48:29.59 .net
- >>472
子供か?
- 475 :仕様書無しさん:2022/07/16(土) 23:57:02 .net
- >>468
極端な例だとstringすら使わずchar[]で全部書いて標準ライブラリも使わず関数は自分で実装
クラス変数は全部パブリックみたいなとんでもないのは見たことがある
まぁそこまで極端でなくても割と組み込みとか制御とかそっち系の人が書くC#はバリバリハンガリアンですforeachなにそれみたいなのが多い
- 476 :仕様書無しさん:2022/07/17(日) 01:18:55.00 .net
- >>475
もう高齢者なんだから許してやれよ
- 477 :仕様書無しさん:2022/07/18(月) 12:42:30 .net
- C#のコーディングスタイルでグローバル変数云々とかヤメレ
staticメンバーならまだ許せる
- 478 :仕様書無しさん:2022/07/18(月) 12:53:52 .net
- >>475
そこまでするんならアンセーフコードもバリバリ書けそう
擁護する訳でないがアンマネージコードで処理したい場合に活用する事がごく稀にある
- 479 :仕様書無しさん:2022/07/20(水) 08:16:51.44 .net
- >>475
まあ、自分勝手な業務外アプリの開発とかなら、それぐらい普通だけどね。
Cが必須ってのは、勉強の一環としてそれぐらいやれってことね。
なんのライブラリ使ってるのか、ちゃんと意識しないといけない。
- 480 :仕様書無しさん:2022/07/21(木) 02:44:47.44 .net
- C言語はどんなマシン語、アセンブラになるのかわかるレベルの人間が使わないと意味がない。
- 481 :仕様書無しさん:2022/07/21(木) 07:51:22.28 .net
- まあ結局はそうなんだけどね。
最近、アセンブラのことが書かれた本もチラホラ見るようになった。
- 482 :仕様書無しさん:2022/07/21(木) 10:40:02 .net
- >>475
代替案あるの?
- 483 :仕様書無しさん:2022/07/21(木) 14:34:08 .net
- >>482
横だけど、標準にあるやつを使えばいいのでは?
多分>>475の「クラス変数」は「インスタンス変数」の書き間違いだと思う
クラス変数ってC++だとstatic付きメンバ変数のことらしいし
打ち間違いだと思う
もしそうなら普通はよっぽどの理由がない限りpublicにはしないと思う
システムハンガリアンは使わずに変数名をつける
foreachが使えるなら使う
とかじゃない?
あとはその言語のコーティング規約を読んで対応するとか
- 484 :仕様書無しさん:2022/07/21(木) 14:37:24 .net
- 地味に言語によってコーティング規約が違うみたいだし
C++ではメンバ関数は大文字から始めるキャメル、Javaだとメソッド名は小文字から始めるとか
- 485 :仕様書無しさん:2022/07/21(木) 15:53:39 .net
- >>483
たぶん元レスはメモリをどこに確保するのかの話だよ
C++としてマナーのいい書き方をしたところでハードウェア的にはマナーの悪い動きしかしない
だから「どんなマシン語、アセンブラになるのかわかるレベルの人間が使わないと意味がない」ってレスが続いてるんだと思うよ
- 486 :仕様書無しさん:2022/07/21(木) 15:59:55 .net
- C#は.NETが公式ガイドライン出してくれてるからありがたい
宗教戦争が起きにくい
https://docs.microsoft.com/ja-jp/dotnet/csharp/fundamentals/coding-style/coding-conventions
staticフィールドがs_hogehogeだったりするのはアレだけど
- 487 :仕様書無しさん:2022/07/22(金) 01:34:44.93 .net
- googleの出してるC#ガイドラインの方が好きだな
- 488 :仕様書無しさん:2022/07/22(金) 01:45:56.81 .net
- Googleのガイドラインはあんまり好きでない
仕事でも圧倒的多数はMicrosoftのほう
だがこれ以上言うと戦争起こりそうなのでやめとく
- 489 :仕様書無しさん:2022/07/23(土) 08:27:47.90 .net
- >>484
C++には大文字と小文字を使い分ける慣習はない。
単語の区切りに大文字を使い始めて普及させたのはマイクロソフト。
- 490 :仕様書無しさん:2022/07/27(水) 21:07:07.13 .net
- c以前の言語は後方互換の為に大文字小文字を区別しないのが多いねFortran, lisp, cobolとか
lispとFortranは書くけど、lispは出力は出力は自動で大文字になるので入力(コード)は全て小文字で書く、replで入出力が一目で分かるので便利な慣習
まあスネークでもなくて独特なkebab-case-pだけど
Fortranはスネークもキャメルも居るけど、repl開発じゃないし大文字にするか悩む合成語の表記揺れてもコンパイル通るので俺はキャメル
- 491 :仕様書無しさん:2022/07/27(水) 21:10:16.45 .net
- クラスとそのインスタンスを大文字小文字違いでしか命名出来ないような奴はOOP向いてない説
- 492 :仕様書無しさん:2022/07/28(木) 09:46:53.76 .net
- どんな言語でもC言語で開発されてるんだけど
- 493 :仕様書無しさん:2022/07/28(木) 20:44:28 .net
- >>492
わざわざ中水準言語を使う必要がないという話だぞ。
- 494 :仕様書無しさん:2022/07/28(木) 21:12:43.71 .net
- んなこと言い出したら今時のスクリプト言語でC言語処理系作る方がよっぽど楽な件
- 495 :仕様書無しさん:2022/07/28(木) 22:47:56.43 .net
- 同じものを作っている時点でやばいだろ
- 496 :仕様書無しさん:2022/07/29(金) 08:03:06.05 .net
- まあ、STL使うぐらいならJavaやPythondで十分という考え方はアリだな。
だから当初から言ってるだろ、STL使わない縛りをまずはやれって。
- 497 :仕様書無しさん:2022/07/29(金) 21:28:38.42 .net
- 言語が低級かどうかは特定の機械語との対応で決まる相対的なものでしかない
x86上のCならローテーション等高度なビット演算や(使う機会があるかどうか別にすればBCD周りの命令)を欠いてるし、結構高級
lispはx86上では高級言語だけど、lisp マシン上ならlisp関数と機械語がほぼ同名で一対一対応する超低級言語、アセンブリそのものだ
- 498 :仕様書無しさん:2022/07/29(金) 22:46:37.14 .net
- いまどき実行速度の話にもっていく人間がいるとは思わなかった
- 499 :仕様書無しさん:2022/07/31(日) 09:00:57.99 .net
- >>491
今回限りの処理で、オブジェクトが一つだけの場合はそれになりやすい…
別の名前にできる場合は別の名前でやるけど
これでも向いてないのか…?
- 500 :仕様書無しさん:2022/07/31(日) 09:18:35.87 .net
- だから言ってるだろ、Cなんてシロウトには無理って。
無理なんだから無理はするな。 素直に出来るやつに任せて、
お前らは出来るやつのために仕事取る営業に専念しろ。
- 501 :仕様書無しさん:2022/08/26(金) 14:54:51.35 .net
- >>492
んなこたあない
- 502 :仕様書無しさん:2023/06/10(土) 19:52:59.47 .net
- この板、C言語おじさん多すぎないか?
定期的に戒めでこのスレタイageたくなる
- 503 :仕様書無しさん:2023/06/29(木) 21:07:02.70 .net
- 組み込みはCだからね
メーカー系にいっぱい組み込みおじさんがおる
- 504 :仕様書無しさん:2023/09/13(水) 22:14:44.35 .net
- 失敗しなくちゃ成功はしない
- 505 :仕様書無しさん:2023/12/16(土) 20:49:43.18 .net
- C++といいながら丸々Cじゃねーかってのはよくあるな
- 506 :仕様書無しさん:2024/03/29(金) 15:20:50.69 .net
- 兼オタなんて出来ないでよww
- 507 :仕様書無しさん:2024/03/29(金) 15:31:37.25 .net
- シーズン
8月17日
- 508 :仕様書無しさん:2024/03/29(金) 16:12:39.04 .net
- 阿呆おるんか
- 509 :仕様書無しさん:2024/03/29(金) 16:24:44.25 .net
- 運動で信者を炙り出して、人生で最大の謎の上から目線で言い、信者名)の確保も必要だし制作側にとってははた迷惑な話だぞ
あと炭水化物があまりに不正利用について可能性あるな
改ざんしてるに決まってるじゃん!
- 510 :仕様書無しさん:2024/04/19(金) 05:28:33.31 .net
- すでにあるものの組み合わせでできるのに一から作るやつはヤバい
- 511 :仕様書無しさん:2024/05/04(土) 17:26:10.23 .net
- Cはポインタのお遊びに使えるけど、あまり実用的ではない
権威ある大学教授がCを学ぶ人は負け組だの底辺層だの散々学生に刷り込んでいるから、若手でやる人は減ってきている
- 512 :仕様書無しさん:2024/05/04(土) 18:09:41.41 .net
- 米ホワイトハウス、開発者にRustなどメモリの安全性考慮した言語への移行促す
https://news.mynavi.jp/techplus/article/20240227-2893479/
脆弱性の特徴を持ち普及率が高い言語として、CおよびC++を挙げている。
このような脆弱性を軽減するために、「はじめからメモリ安全なプログラミング言語」の使用を推奨している。
レポートでは、その具体例としてCおよびC++を「Rust」へ移行することを促している。
118 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200