【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の無作法と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はマルトルーシュカのイメージある アセンブラってオブジェクト出すツールで、コードはアセンブリじゃないの? コンパイラ->アセンブラ->リンカ コードもアセンブラって呼ぶの? 周りでもそう呼んでる人だらけだけど。 >>570 脳内でこんな分類をしてしまうような奴が 言語を扱うこと自体が危険 アセンブラーはアセンブリ言語で書かれたプログラムを機械語に変換する開発ツール >>607 16進数な機械語でPG可能です アセンブラを完璧に熟せるクラスにまでテクアップできると 機械語で直接入力できます Z80系の石でこれができました しかし、暴走もそれ以上に得意技になりました intelだってarmだって出きるだろ exeやelfをバイナリエディタで作成する程度、まともなエンジニアなら普通に出きるぞ メインフレームは〜弾道計算とか爆縮レンズとかの戦争目的からスタート 企業会計システムで華が咲く PCは家電に近いと思う 最初はゼニ儲けが目的じゃなかった マニアが趣味的に始めたこと 「蓼くうものも好き好き」 「好きこそ〜モノの上手なれ」 >>15 誤植(誤訳?)も多いしな いきなりa.outとか言われても訳が分からなかった >>606 わからんけど、リミテッド・スリップ・デフじゃね? PCの最初はマイコン=電卓ICしょ やっぱり金儲けよ アセンブリ言語をアセンブラでアセンブルすると機械語になるわけですよ >>595 Pascalが五徳ナイフとか全く分かってないよな delphiじゃないんだから >>600 Haskellはイギリスの関数型言語文化だよ オランダやフランスもちょっと混じってる WikiでAssembly languageをみたけど、単にsource codeだった。ツールはアセンブラ。 >>598 > MySQLのないPHPは実用的に使えない ふむふむ > Ruby / Perl /Pythonは分野が限定されすぎ ほー > C / Pascal / Visual Basicは原始的 んー > Assemblyは今でも使えるが専門的過ぎ(機械言語に近いので) ガクっっ アセンブラと機械語は同じだよ。 近いとかじゃなく。アセンブラの命令が1対1で機械語に対応してるの。だから逆アセンブルできる。 いちいち16進数打ち込むのがだるいから、アセンブラ使ってるのよ。 変数名代わりにラベルも使えるしね。 さてはどの言語もろくすっぽ使ったことないな。 Pascal は十分に高級だよ。Pコードも含め。 セキュリティについてはCが悪いんじゃなくて、メモリ管理をOSだけでやろうとしてるからやで。 もともとインテルのプロセッサにはメモリ保護可能な機能が備わってる。 >>602 そのへんは適当だよ。 アセンブラ : アセンブリ言語を解釈して機械語に変換 ところが、アセンブラ入門とかって本が山ほどあって、アセンブリ言語を、アセンブラ言語とか言ったりしてる。 わかれはいいんじゃないの。 assembly は「組み立て」るって意味。 assembler は組み立て工って意味。 組み立て工が、組み立てを組み立てる、わけがわからないね。 mnemonic てのもある。こっちは、記憶を助ける、って意味だ。 機械語を、覚えやすくしたもの、ってことだね。 >>624 アセンブラと機械語が同じ? ニワカ過ぎて話にならんな c/c++って、言語とマクロの2本立てだよな マクロをひたすら駆使してプログラミングすることの良し悪しはあると思うが マクロとメインの言語を分離せずに一体化した言語仕様というのがあってもよさそうだが 最近の言語はどうなんだろう C++のテンプレートなんかは、コンパイラ内部ではマクロ処理みたいなことをやってるんだっけか >>628 cpp は他のものに対しても適用できる。 cppがやってることを理解さえしてれば。 >>624 複数命令にアセンブルするとか 必ず一対一にアセンブルするとは限らんのよ マクロアセンブラとかもあるしね >>631 1対1でないものは、○○アセンブラていう派生。マクロアセンブラもそう。 アセンブラ使うなら、機械語にどう変換されるのか確定的なものまで。 なんとなく便利だなでいいなら、Cにしとけ。逆アセンブルして、再現されないのはアセンブラとは言えない。それは高級すぎるから。 機械語の1個上の低級なポジションがアセンブラ。 ScalaとKotlinは嫌い valとvarが紛らわしい letとvarが良い >>632 マイクロコードと命令が一致してないって意味だよ アセンブラを書ける層って年々減っていって、ロストテクノロジーになったりしないのかい? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる