【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/ バイブルである「プログラミング言語C++ 第4版」をトイレに置いて毎日少しずつ読んでる 何年もC++やってるけど新たな発見が多すぎてなかなかションベンも出ない C言語と同様に速度も求めたいが 大規模でオブジェクト指向的に組みたいときは C++使いたい場面もあるんだろうな クラス単位でメモリアクセスの妥当性の確認とか リソース解放をやっておけば、メモリ関係のトラブルも減らせるだろうし vector やら string やら使えばメモリ関係の処理をライブラリにまかせられるし ANdroid NDK叩くだけならRustで十分だろうな >>503 それ、尿道結石か、膀胱ガンじゃないの? >>497 メッセージパシング機構ね そしてこのアクター(スレッド)どうしのメッセージパシングこそが真のオブジェクト指向だと言われている それを言語として実現してるのはErlang ちなみにErlangはC言語で作られている スレッド間の排他処理なら、セマフォか、クリティカルセクションだろ。 プログラムだけじゃなくて、脳みそに虫湧いてるんじゃないか? >>466 Cを使うと言ってるのに なんでガベコレがでてくるのか わからんな Cでガベコレが出来ないとでも? そうそう、マルチスレッドの強みはメモリ共有で性能追求できることだもんね ちゃんとロックして同期するだけのカンタンなお仕事 しかし、ゆとりはスレッド切替のコストも知らない・・・ >>507 Erlangのベンチ見たんだが、8コア全て100%使い切れるんだけど、 C++の8倍遅くて実行時間は一緒だったという微妙な結果だった。 そりゃ、Erlangの採用進まないわな >>511 シングルコアマルチスレッドでスレッド切り替えのコストがか狩るのはわかるんだが、 マルチコアマルチスレッドでのスレッド切り替えのコストってどうなんだろう? もちろん、スレッドを分別なく作るんじゃなくて、コア数分のスレッドだけ作る パイプラインみたいな構造にするとして >>511 そして、老害はメニーコアの時代について行けない・・・ >>386 Pascal式は、文字列の長さが想定を越えると破綻する。 「カーニハンの呪い」 64KのメモリしかないPDP11上でマルチタスクマルチユーザのOSを記述する為に開発した、最適化も出来ないC言語を、日本のお馬鹿なソフト会社はその必要も無いアプリ開発に適用し、ポインターも解らぬPGにカーニハンの教科書を与えて開発させた。 その結果アプリは予想外のエラーを吐き続け、殆どのプロジェクトは終了しないまま頓挫した。 これにより、日本で何兆もの費用と、IT発展の貴重な時間が失われた。 OSやデバイスドライバもかける、速度が速い、 ちょっとでもミスすればすぐにバグで動作異常になったりセキュリティホールができたりする たとえるならF-1カーみたいなもんだな 問題なのは、それを一般アプリ開発にまで使用してる点 一般人がF-1カーで通勤したり買い物にいって事故おこしまくってる感じ 現代のPCやスマホ、とくにGUIアプリの標準開発環境がC++ってのが悪い >>512 どんなプログラムで比較したのか 逆にErlangにメリットがないならそもそもErlangで試したこと自体ナンセンス そんでErlangのメリットって速さだけじゃなくて、並行プログラミングやリカバリの基盤が揃ってることとかもあるからねぇ それらをC++で実装しようとすると結局Erlangを再発明することになるだけなんだよ >>522 標準がC++のプラットフォームなんて聞いた事無いが いい加減数値解析の分野でもFORTRANに引導を渡してくれ >>1 Rustで書き換えるくらいじゃどうにもならない >>520 F-1カーでも速度に影響ない範囲で安全な方がいい >>454 ビャーネ・ストロヴストルップの名前を見て、これを思い出した。 http://www.kh.rim.or.jp/ ~nagamura/misc/stroustrup-interview.html 自分もウソだと信じたい。 >>517 >C言語野郎はなんでもループで回したがる やっぱ再帰だよなw >>530 まあジョークだと思うけど 内容については辻褄が合ってるという非常に同意できる Cの無作法とJavaの回りくどさを 双方あわせもつ言語C++ >>524 WindowsもMFCがバージン3の頃はそうでしょ >>454 C++はコーディング規約のある仕事ならそれに従っていればいいんだが 独自にあれやりたいこれやりたいということであれば Addison-Wesleyのprofessional computing seriesのC++のやつ、C++ in-depth seriesを一通り読まないと駄目 最低でもまとめ的な「C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス」は必要 それでも並列やWinの構造化例外はカバーしてない >>539 C++ in-depth series、残念ながら日本語訳はほとんど古書扱い 日本語訳が残念なものもあったね ざっと見渡すと書斎に9冊(原著3冊)、残りは職場だな >>540 まあ必要な人は原書読める人が多いからね 技術書なんて英語力悲惨な自分ですら 英語の原書の方が圧倒的に分かりやすいからな >>542 うん、もう少しがんばって訳して欲しい。 プログラム関連の本や企画書(これはダメだよ)で、 文中に出でくる関数名やメソッド名を翻訳してしまうのはやめてくれ ところでRust がC++と同等の実行速度というのは本当なのか LLみたいにCで作ったライブラリを呼び出しといて速いとか言ってるんじゃないのか? 出版社が改訂する人的リソースも割いてない ハウツーの方が儲かるからな >>544 応用によってはありうるでしょ Javaだって応用によってはC/C++より速いし JITのお陰で でもRustで書いたライブラリが OpenSSLの代わりが勤まるかというと違う >>546 ニセモンだよ 初期のC++にはテンプレートはないから Hello, World!くらいで実行形式は増大しない iostreamもまだない C++、というかC with Classの初期の論文も読んだことない生半可な奴が書いたレベルの低い創作 セキュアな環境はどうやって構築されているのか考えたらナンセンスな主張だとわかろう >>547 Javaなんかと同じで特定の都合がいい条件を用意した結果だけを出して同等とか言ってるってことか JITでもまともにコーディングしたC++に最適化かけたものより速くなるわけ無いじゃない。 JITで速くなるのは最内ループに分岐があるが実データでは常に同じ方向に分岐するようなコードとかでしょ。 でそれが実際にはループ外で判断できる場合じゃないとJITでも分岐削れないからそういうコードかけよとなる。 >>552 ホットスポットはプロファイル取って 統計情報に基づいた最適化 アンローリングなんかも やるかやらないかどの位するか 実測値に基づいてやる C言語は、通信、制御系の雄者 雄叫びは定期的に挙げます セキュリーホール・・・アフリカのサバンナで生息してるライオン君 Cどころか、Bにも達したことがない俺はどうしたらいいんだ!!! >>559 そんなことしたら、俺C++になっちまうだろ 手がつけられなくなるぜ >>560 Cすっ飛ばせば「死を」とか言われなくて済むからいいな 実はJNIにつないでいるオチだろ そりゃ同等に速いわ >>547 > でもRustで書いたライブラリが > OpenSSLの代わりが勤まるかというと違う なんで? >>572 COBOLはブロックチェーンの進展次第で本当に根絶やしになりそう まじでメシウマ 巨大銀行はなぜブロックチェーンを研究しているのか? https://wisdom.nec.com/ja/technology/2017022101/02.html >>566 >処理系はJVM上で動作するため ないわー >>566 http://x1.inkenkun.com/archives/179 Python でさえ、NumPy とか使わないといけないのがダルいのに、 Scala って、なんでこんなに解りづらいの? import javax.imageio.ImageIO; import java.awt.*; import java.awt.image.BufferedImage; import java.io.File; import java.io.FileInputStream; import java.io.IOException; import java.io.InputStream; 頭痛くなった。 これ、javaしか使えない奴向けの救済キットやろ、筋が悪すぎる。 >>575 ,576 F#との比較なら同じようなもんじゃないか?Scala >>537 「Cの無作法とJavaの回りくどさ」」 これ頂きます 野獣の「C」が作法を持ったら死ぬ 東南アジアのジャングルや〜 中央アフリカのサバンナで雄叫びを揚げる「野獣」 それがCです Cをてなづける、完全コントロールするって行為は 野獣を鉄格子な「ZOO」に放り込むという無謀な行為 野獣性の無い「C」に何の魅力も感じません >>569 速度が必要とされるアセンブラもどきのコードが沢山含まれてるから >>578 んーー F#は既に死んでいるのでナシ RとPythonは使える。 C/C++も場合によっては使える。低級言語として。 pythonで C/C++コードを自動生成するのが最強 >>580 rustはインラインアセンブリ書けるから大丈夫じゃね? >>582 つまり、Cython 別に、Cでもいいよ >>583 asm文じゃなくてCで書いてある アセンブラで書いたソースファイルも含むが それが存在しないCPUでのビルトは Cで書かれたアセンブラもどきのコードが使われる >>570 C++邪悪すぎ そしてPerlこんなにかっこよくないだろ よくわからんがプログラム言語自体にセキリティホールがあるとか本当にあるの? 仕様はともかく、標準ライブラリが糞でセキュリティホールが!なんてのは普通 まぁ世の中にはセキュリティなんてくそ食らえ! 自由であることこそ至高!なんて設計思想の奴もあったやうな? >>586 常に主語が省略される自然言語は日本語ですよ。 >>587 プログラム言語によってセキュリティホールを作ってしまうことを防ぐことはできる(全部を防げるわけではない)。 >>585 1024 2048 4096 ----- ----- ----- no-asm 30 148 916 asm 13 46 283 こんなくそじゃまくさいのをようやるな ROM化なんてやったら糞w >>586 リンゴの皮を剥くときに日本刀しかなかったら困るだろ 木を切り倒す時に、十徳ナイフしかなかったら困るだろ 燃料投下 20の言語/環境でてきとうにベンチマークしてみた (Rust, Go, Crystal, Nim, Swiftなど) http://safx-dev.blogspot.jp/2015/11/20-rust-go-crystal-nim-swift.html > 最速はOCamlとSwift > Goのシングルバイナリ感がすごい > Perlは実行速度は遅いが、起動の軽さとメモリ利用量の少なさがよい > PythonはRubyより遅いのね… > Rustは1.4.0になって、Cと同等の速度になった (1.3.0はCの4割くらい遅かった) > CrystalはだいたいC同じくらいの速度。ただしコンパイルは遅い > Juliaは起動が遅いが、それ以降はコンパイラ言語並みに早い > PyPyの速度の不安定さ。ちゃんと使うならチューニング必須 > Luaのいろいろな軽さ >>570 c++とjsは分かる 他は意味分からん >>597 MySQLのないPHPは実用的に使えない Ruby / Perl /Pythonは分野が限定されすぎ C / Pascal / Visual Basicは原始的 Assemblyは今でも使えるが専門的過ぎ(機械言語に近いので) 俺はこういう解釈 これ以外の言語は使ったことないのでノーコメント >>570 Haskellだけヤク中じゃねーかwww >>599 当時の西海岸を鑑みるとLと葉っぱとベトナム戦争とヒッピーの相乗効果によってコンピュータ業界そのものが肥大化したと思っていい なのでその流れを汲むと信じられているハスケルは伝統的な意匠を受け継ぐのでキノコ=MMの絵となる LISPの折れたフォークが解らん なんかの隠語かな LISPはマルトルーシュカのイメージある アセンブラってオブジェクト出すツールで、コードはアセンブリじゃないの? コンパイラ->アセンブラ->リンカ コードもアセンブラって呼ぶの? 周りでもそう呼んでる人だらけだけど。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる