【IT】C/C++に死を [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
プログラミング言語Cはおぞましい。いや、素晴らしくもある、もちろん。私たちの住む世界の大部分はCの上に作られている。そしてほとんどのコンピュータープログラミングの基礎をなしている、歴史的にも、実質的にも。Xavier Nielの革新的な “42” スクールのカリキュラムが、学生に標準Cライブラリー関数を一から書き直させることから始まるのはそれが理由だ。しかしCは、C自身が作り上げたこの世界にとってもはやふさわしくない。 「おぞましい」と言ったのは「悪い」ということではなく「畏敬の念を起こさせる怖さ」という意味だ。Cはモンスターになってしまった。あまりに多くの大砲を与えたためにユーザーは自分の足を撃ち抜いてしまう。豊富な体験が教えるところによると、セキュリティーホールにむしばまれることなく大量のCコードを書くことは非常に困難であり「事実上不可能」になりつつある。2年前、私は最初の「Cに死を[Death To C]」の記事にこう書いた: 原理上、ソフトウェアが成長し進化して成熟度を増すほど、セキュリティー脆弱性は複雑になっていく。しかし、C/C++で書かれたソフトウェアにそれは当てはまらない。バッファーオーバーフローや宙ぶらりんのポインターのために壊滅的セキュリティーホールが生まれる事態は、繰り返し繰り返し起こっていて、昔も今も変わることがない。 私たちはこれ以上巨大な口を開けたセキュリティーの盲点を放っておくことはできない。引退して別の言語に取って代わられる時期はとうに過ぎている。問題なのは、ほとんどの近代言語はCを置き換えようという意欲すら持っていないことだ。〈中略〉どの言語もCが最も得意とすることに長けていない ―― 例えばシステムの奥深くまで掘り下げてマッハスピードで動くこと。 あなたがデベロッパーなら、私の言いたいことはもちろんわかっているだろう。Rustの長所を並べることだ。実際これは有望なC/C++の後継だ。2年前に私は、新規の下層レベルコーディングをCではなくRustで書くことを勧めた。つまるところ、穴に関して何よりも大切なのは、掘るのをやめることだ。 Security tips when programming in C (2017 edition): 1) Stop typing 2) Delete what you've already typed [Cでプログラミングする際のセキュリティー心得(2017年版): 1)タイプするのをやめる 2)すでにタイプしたものを削除する] 今私は、エンジニアが既存のCコードをリファクタリングするとき、特にパーサーなどの入力ハンドラーを書き直すとき ―― ゆっくりと、すこしずつ ―― Rustで置き換えるように真剣に勧めている。 http://jp.techcrunch.com/2017/07/17/20170716death-to-c/ >>275 今時の家電製品などで使うような専用ICもピン数を減らすなどの理由で電源を入れるだけでもシーケンス動作が必須だったりするんだよ 電源ONの時にいくつかのICにシリアルのコマンドをいくつか投げるとか、ボタンを押した時にスイッチのON/OFFではなくてエンコードしたシリアルの コマンドを送るような用途なら小物の部品感覚で使えるPICのような「シーケンサ」が適している 結局問題提起すら読まず理解しない者がCを使うからセキュリティーホールができてしまうのだろうな >>1 リンク先で言われているバッファオーバフローやポインタの問題は、 最近のC++ならほぼ解決しているけどな。正直生ポインタなんて最近使わないぞ。 DBのOracleがJavaに移行したのは衝撃だったな >>37 知ったかだなぁ 文化的な背景なんて関係ねーよ 以下3点が理由だ ・(組み込み環境で主流の)linuxやtronのデバイスドライバがCでしか書けないから ・(言語的に単純な)Cが一番早く開発環境揃うから ・Javaとかも動かせなくはないけど(スマホとかのリッチな環境でも無けりゃ)クソ遅い&重いから リッチコードが使えない組み込み機器なんかじゃC以外考えられないわ Cなら1MHzで動くコードもjavaが動く組み込みになると48Mhzとか当たり前のように要求されるからな バッファオーバーランなんて言語じゃなくOSの問題だろが >>83 初心者が使える程度の言語に存在価値あるのか? >>331 難解な言語じゃないと存在価値ないとか意味不明 >>333 難解さ容易さが問題なのではない。 何ができて何ができないかだ。 初心者向け、あるいはその言語で解決しやすいように整えられた問題に対して、 出題者の意図に沿ったコードを書くのは、初心者向け言語には容易だ。 だけど、世の中にある仕様は、その人の都合を考えてくれるわけではない。 >>294 ということはメーカーが一括購入したらもっと安いのね。 >>330 OSやライブラリの問題 APIがバッファ長を必ず要求するようにしとけば、バッファオーバーフローは起きない >>338 Javaは配列の代入で必ず長さチェックがかかる仕様なんだよな 最初はバカにされていたけど、今となっては大正解 >>339 それを入れなきゃならんOS仕様の問題だわな。 シンビアンなんて、電力管理をプログラミングに求めてた訳で >>338 バッファを使うのはAPIだけじゃないんだけど。 >>338 そもそもそのOSやライブラリをを書くために使われる言語についての話題だと理解してる? >>340 仮想化支援みたいな感じであんまオーバーヘッドがあるようならCPUとかハードでの支援機能があってもいいかもね (バッファオーバーフロー対策のハード支援はあったと思うから、もしかしたら既にあるかもしれない) もうC/C++とか超えた世界の話 javaは、androidとWebだけ。 C#は、windowsのアプリだけ。 c/c++は、すべての分野で使わエる。 >>292 NXPのLPC800とか、100円台で買える32bitマイコンもあるが、ボタン電池で 動かすとかだと、消費電力が大きくて使えない。 androidもスピードが要求される部分では、 jniでつないでc/c++で書かれている >>339 いくら代入で長さチェックしても、範囲チェックしないで、要素数を超える 配列要素にアクセスするバカはいるので無駄。 速度の為に余計なコートが混じってほしくないってだけのがC言語 セキュリティの問題もあるし、もう封印しちまえ。 死ぬべきなのは、C++言語ではなく、ついてこれないプログラマの方。 >>348 多分それもやってるよ。 JavaだとそこらへんExceptionになったと思うけど、それが長さチェックをやっているってこと javaはデストラクタがないから、ガベージコレクションが走るように、 明示的に的にnull設定しないといけない。 安 倍 晋 三 の 実 兄 、 安 倍 寛 信 三菱商事の核ミサイル担当重役は安倍晋三の実兄、安倍寛信 三菱重工の重役でもあるらしい これがフクイチで核弾頭ミサイルを製造していた疑惑がある 書けばツイッターで速攻削除されている 私のツイートで、安倍政権に都合の悪い情報は速攻削除されている これは驚いた ここまでやるのか https://twitter.com/ 東海アマ/status/841451580339625984 3 9 歳 で 若 年 性 ア ル ツ ハ イ マ ー 2015年1月には、首相官邸で安倍首相と意見交換する機会を得て、 認知症になっても働くことができるということを伝えました。 でも、症状は着実に進んでいます。 https://twitter.com/onodekita/status/881710709624627200 世 界 教 師 マ 人 ト レ ー ヤ か ら 警 告 (まもなく、日本発の株式大暴落、次いで米国債大暴落の後、各国メディアに登場、UFOも) 認知症の過程は放射能汚染によって加速します。 若年性アルツハイマー病の原因となっており、 人々は肺炎やインフルエンザ、慢性疲労、癌、 HIV/エイズなどに抵抗できなくなっています。 免疫システムの崩壊の結果がアレルギーです。 死者の数は、他のいかなる原因よりも多いです。 河川の汚染は犯罪と見られなければなりません。 問題は、日本政府が何も認めないことです。 多くの人々が放射能の影響で死んでいるのに、 彼ら(日本国民)は幻想の中に生きています。 日本の近海の食料は安全ではありません。 健康上のリスクは福島に近づくほど高まります。 福島の子供達は癌をもたらす被爆をしています。 福島の住人は廃炉後1、2年で戻れるでしょう。 マ人トレーヤは原発の閉鎖を助言されます。 マ人トレーヤによれば、飛行機など原子のパターンが妨害されると墜落します。 マ人トレーヤはいかなる人間よりも危険をよくご存じです。 マ人トレーヤの唇からますます厳しい警告と重みが発せられることを覚悟しなさい。 おれ、CASL2しかやったことないんだけど、CとかC++とかやるべきなのかな? >>1 人間が会話に使う言語と違ってプログラム言語はコンピュータは最近の人工言語なのに、なんでこんなに種類があって複雑なの? >>357 神様がプログラマーに罰を与えるために言語を分けたって聖書に書いてあるらしい >>55 サブマイコンとしてならいっぱいあるよ。 それこそソニーやパナでも使っている。 >>357 C/C++が出来れば、大抵のことはできるよ。 >>357 自然言語は勝手に言葉をつくっても 他に話す人がいないと意味ないから まったく新しいものは生まれないけど 人工言語は人工だからこそ、いろいろ生まれるんだろうな ここが気に入らない、ここはもっと改善できると思った人が 新しいものを生み出す javaのruntimeとかVM系は大抵c++ と言うかLLVMもgccもc++だから 言語なんて何でもいいよ、Application開発に最適であれば。 >>363 でもpythonで10行で済むコードが 1000行になったりするけどな 型と必要リソースが厳密なのは 利点でもあるが面倒臭くもある boostとか持ち出すともはや別言語だし >>135 昔、IBMがJavaのWindows用のネイティブコンパイラ出して Sunに怒られてたような記憶が・・・ Cを代替する言語は現実には無いからね。使わざるを得ない。 アセンブラはクリティカルな部分以外に使うのは非効率過ぎる。 煉瓦で超高層ビルを建てるぐらいアホくさい。 C++は半端に拡張してしまったのが問題だろうね。 Cみたいにコードが予測がつくほど低レイヤー言語ではないけど 抽象化が半端で記述の効率化がろくに図られてないという。 >>368 Excelsior JETはAOTコンパイラでネイティブコード吐けるけどOracleにJava互換認定を受けてらしいよ。 今はLLVMでもJava バイトコードをネイティブコードにできたんじゃないかな? Excelsior JET https://www.xlsoft.com/jp/products/jet/ > Excelsior JET は、JCK (Java Compatibility Kit test suite) をパスし、 > Oracle からライセンスされています。さまざまなプラットフォーム上において Java 互換認定を受けています。 >>367 それはないな。たとえPythonで書かれたライブラリに相当するC++ライブラリ がなくても、Pythonで書けるコードはC++でも書ける。どうせ、行末文字の セミコロンや、{}の省略くらいの節約なんぞ、生産性への影響はないに 等しい。 は、 >>278 ocamlはいいね。 もっとマルチコア対応してくれたらいいのに。 >>15 簡潔にして明瞭、まさに聖典 アレを読んで理解できない奴が他の初心者本読んでも、理解したつもりにされているだけで本質はなにも理解できてない 100年後もCは死んでないと断言できる まぁ俺は間違いなく死んでる訳だが >>367 pythonで簡単にできるような機能なんてライブラリ化されているから、自分で書くコードとしては20行もあれば終わる。 C/C++の生産性がスクリプト言語並みだし、WebアプリケーションはみんなC/C++で開発されているんだよ このスレでの定説 >>382 このスレに書いてあることは全部素人の書いたデタラメって言っているのと同じようなもんだな(´・ω・`) >>348 例外発生してサイレントクラッシュしないだけでも意味がある。 PythonよりもC/C++をやったほうがプログラミングの勉強になるだろ。 Pythonはその後でも遅くない。 >>322 > DBのOracleがJavaに移行したのは衝撃だったな サンマイクロを買ったら、おまけで付いてきた オラクルが欲しかったのは、DB特化型のサーバーかな 何もしていない普通の一般人の自宅に隠しカメラを取り付け それをネットでリアルタイム配信 仲間という人間に対する盗聴盗撮生ネット配信の会 しかけたカメラの映像 乗っ取っているPCの画像をリアルタイムで生配信中 集団で仲間の私生活を覗いて楽しんでいる そんなことが今この国では行われています >>390 Javascriptがないという点で統計としては問題のある研究がソースだが、これを見ると言語の傾向が分かる https://blog.sourced.tech/post/language_migrations/sum_matrix_25lang.svg C++をGithubで最近アップロードした人間は、Pythonを次にアップロードするということ C++からRustは少数だが、C++からJava、PHP、Rubyを次にアップロードする件数は多い >>327 Luaはコンパクト プログラムにLuaを組み込んでも太りません。 配布されているバージョン5.1.4の tarファイル はたった212Kバイトで、 ソースコード、ドキュメントおよびサンプルが入っていて、 展開しても860Kバイトです。ソースコードは約17000行のC言語。 Linuxでは標準のLuaライブラリを含むLuaインタプリタは153Kバイトで、 Lua言語本体の実行時ライブラリが203Kバイトになります。 8bitでは走らないね Luaはいいと思うよ。普通の使い方なら。 Cでないとしょうがないジャンルはあるね。何しろ、使いやすいアセンブラなんだから。 Cで言われてる問題は、言語構造の問題でもあるけど、CPUが根本的にかかえてる問題。 64ビットのCPUの命令を見直せば、セーフティなCになるか、より安全で高速な言語が作れる。 セーフティを求めてVM使ってる限りは、Cは生き残る 安全装置外した方が速いんだから。 CPU自体に安全装置入れろってこと >>332 Hi-Z状態は重要。XOR回路書いてみ。トランスファゲート使った方で。 >>394 負のスコアへ調整した後の結果 https://blog.sourced.tech/post/language_migrations/erik_red.png これによるとJavaとC++、PythonでGithubに書き込むのが多いが golangが意外に強い、むしろ圧倒的に増えてるように見える pythonの次はgolangを書き込みのも多いように見える Pythonとか勝手にメモリ管理するほうが怖いと思わないの? javaからgolangのスコアの高さは異常値だと思うのだが、java開発者とgoの関連性が見えないな cやc++でもワンライナー行けるよね バイナリちょっと作りたいときとか まあinclude書くのがちょい面倒だが C/C++っいうセットにした書き方スゲー違和感ある CとC++って別物だろ? Cは好きだけどC++は嫌いって奴も多いだろ ライナスみたいに なのになんでC/C++って切っても切れない仲みたいにしちゃうんだよ? コンパイラがほぼ一緒くただからじゃね? つーか混ぜて書くのも普通だし、ccだけど実質cなのも多いし >>337 > ということはメーカーが一括購入したらもっと安いのね。 多分凄く安いんじゃないかな。最近の情勢は知らないけども、3ピンのトランジスタが、1000個で3000円。小売店でね。 テーピング納品で10万個なら、もっと安いだろう。PICは8ピンあるんだけも、8円でもおかしくないよ。 プロセス微細化で、もう、ほとんどの領域がI/Oパッドなんじゃないの あと、ダイシングって言って、シリコンウエファから切り出す時に、無駄な領域が出る。 なのでロジック部を減らす価値がかなり低い。 とすれば、パッケージング代金だけのようなもの。しかし、1円節約できたら、1億台で、1億円の節約。製造業は厳しいね。 GC任せの言語がメモリしか管理してくれないのはどうにもならんのかね? https://blog.sourced.tech/post/language_migrations/sum_matrix_wdiag_25lang_eig.svg これを見るとFortran、MatlabとRの次にPythonを書き込むのが他を圧倒して多い、Pythonユーザーの多くがプログラマーではなく統計や科学計算をやってるアカデミア出身者ということが分かる ノンプログラマーのための言語・スクリプトというのが分かりやすい Rustと最も関係が深いのがHaskell、次にClosureとGo >>193 今時そんな糞な環境あるかよw とか、思ってたら、この間仕事でスタック128Bytesをやることになった… RAM自体は4KBと潤沢だったが… ARM以外のプロセッサ触るのマジで久しぶりだったわ >>397 https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png これも興味深い。 Rubyの凋落… PHPはくそ、とえぞえなんとかさんがいつも言ってるが、ポジションがある。Rubyよりもある(笑 Python伸びてない というか昔伸びたんだね Java人気だね C/C++ 絶滅危惧種じゃないか C#に乗っ取られそう マイナー言語が、長年小さなポジションずっと持ってるのも面白いわ >>394 は全期間の傾向 ネットで拡散されている図は固有ベクトルの16年間のプロット The thickness of each band corresponds to the value in the dominant eigenvector. https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png 問題点はGithubの2000年時と2017年時のユーザーの差だろう Githubは学生やアマチュア、ノンプログラマーも使うようになった結果としてユーザー数が顕著に増加しているため、 ノンプログラマーが選ぶ言語が最も増える 2008年Githubユーザー数:40000 2012年Githubユーザー数:2760000 これを開発現場で使ってるものと誤認して、その言語を使っても就職・転職活動で痛い目に合うと考えるので注意すべきだ セキュリティやら質の悪いコーダーやら よその原因をなぜ言語に持ち込む? >>407 2008年Githubユーザー数:40000 2012年Githubユーザー数:2760000 統計として意味はないので、指標を信じるのは止めた方が良い Win32ネイティブ開発してたときはC++メインで使ってたけどその頃と比べたら大きく仕様が変わってるらしいね もうC++使えるとか言えないわ >>371 こういうのあるんだ。勉強不足だった。 たた、逆コンパイル出来ないのは、ろくに引き継がれもせず、 さらにそれを引き継いで、jadで逆コンパイルしてなんとかなった 経験からすると怖いな。 まぁ、逆コンパイルなんて出来ないのが本来は当たり前なんだろうけど。 >>404 > GC任せの言語がメモリしか管理してくれないのはどうにもならんのかね? 他に何を管理しろと? CでもmallocでOSからメモリをもらってくるだろ これらは、1KBとか4KB単位で管理されてる それで、ぐちゃぐちゃになったら、OSとCPUが面倒見てるんだよ 粒度の違い VMがやってるかOS+MMUがやってるかの違い まあ単純に率で出してしまうとボリュームの大きなビギナー需要で実用性高いものが薄められて、逆に傾向がつかめなくなるな 人工知能分野でpython流行っていると言っても、本体は実はc++で書かれていて、ラッパを通して使うグルー言語として伸びていると言うのが本当のところだし。 >>407 >>410 2008年Githubユーザー数:40000 2012年Githubユーザー数:2760000 で指摘したとおり16年間の推移を示す図に欠陥があるので、>>394 の全期間の統計図の方が価値がある アメリカでも使えるJavaが強い点はともかく、就職・転職でこの図を信じたら日本はともかく海外では就職・転職では厳しくなる 誤った情報を使ってアメリカへの移住を減らす行為は悪党の行いであり注意すべきだ >>413 ハードウェアリソースの所有権とか DBとのコネクションとか、メモリより厳密に管理すべきリソースはいくらでもあるだろ。 >>72 デルファイいいよな なんで普及しなかったのか不思議 >>416 もっと具体的に書いて > ハードウェアリソースの所有権とか I/Oの排他的処理をCPUがするの? > DBとのコネクションとか、メモリより厳密に管理すべきリソースはいくらでもあるだろ。 TCPをCPUが全部受け持つ? OSで十分なところはOSがやればいいんじゃないかな OSも正常、C言語も正常なのに、穴があるとかSEGVで落ちるとかは十分具体的な問題だと思うけども 穴があったりするの? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる