【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はさわったけど、C++なんかさわる気が起きない… 【スクープ】稲田氏、組織的隠蔽を了承 PKO日報、国会で虚偽答弁[共同通信][07/19]★5 [無断転載禁止]2ch.net
http://asahi.2ch.net/test/read.cgi/newsplus/1500424551/ デストラクタ使うだけでもCじゃなくてC++使う価値があるよね C++は、Cと比べるとちょっと高級すぎるんじゃないかな >>470
そうおもう。
でも、javaは無いんだよね。
ガベージコレクションを正しく走らせるために、
そのクラスが終わったと思われるタイミングで、
明示的に変数にnullを設定しなければならない。
逆に不便。 ポインタを理解できない連中には豚に真珠だけど、スマートポインタを
使えば、リソースの開放忘れとかも容易に防止できるしな。 >>465
Linuxの開発者のライナスはCは好きだがC++は嫌いだと公言している
ライナスもCを理解してないというのか？ >>473
スマートポインタの仕組みをどう実装してるか知らない奴には豚に真珠だけど、
メモリも負荷も余分にかかるんだよ >>475
スマートポインタを使う事でメモリーも負荷も余分にかかってしまうような場合は、
そもそもスマートポインタを使う必要ないのではないかと。 >>454
いろいろ困ってそうなんだけれども
例外、並列処理となると、まずは例外安全性保障かな？
RAIIクラスを導入するとスッキリするかもね >>476
いやいやポインタをdeleteしないことによるメモリリークを防げる
C言語はその辺りをプログラマがめんどうみないといけない
なので、めんどうみれるプログラマはスマートポインタなんて使わなくてよい
そしてC++も必要ない
Cで十分だとなる ポインターが諸悪の根源なら、ポインターの機能を完全に取り除いた
新しいC言語を作ればいいんじゃないの？ だから変数の実体をクラスでWrap(隠蔽)してメモリリークしそうなアクセス要求にたいして例外ヴん投げる親切な言語が重宝されてると
(´・ω・｀)b >>478
実際には面倒を見る必要性を知らない人ほどCで充分って言っていることの方が多いがな >>427
そしてそれを使いこなして江ノ島で猫とたわむれたのが・・・
もう名前忘れた >>481
C++を使いだしたら、C のみといわえると使いにくい。
stl（Standard Template Library）は、かなりいいよ。
コンテナ（string、vector、map など）をつかえば、
ほとんどポインタ操作の必要ない。
アルコリズムもあって、自分で実装しなくても使えるので便利。 >>481
そして、面倒を見られる人もCで十分っていう
中途半端に面倒を見る必要性を知ってるけど面倒見られない奴がスマートポインタとかガベコレに頼る >>483
コンテナはいいね。
範囲チェックありのat()
範囲チェックなしで高速アクセスの[]演算子 >>478
C/C++で開発やってると不具合ってほぼほぼポインタ周りのトラブルに収束するのよね。
しかもポインタ持ってたのに、稀に他のスレッドから開放されちゃうケースがあるとか
そういう再現が面倒なのばかり。 >>484
C++で書いたとしてもスマポ使わなくてもいいんだよー >>486
素直にスマートポインタ(std::shared_ptr)を使いなさい。 androidは、javaのみと思っているかもしれないけど、
スピードが要求される部分は、ｊniでつないで、
c/c++で書かれているんだよ。 使いこなせないロートルと、若年性痴ほう症のゆとりは見苦しいと、
50代専門卒が言ってみる。 つか、unique_ptrならそもそもオーバヘッド無いから、敢えて使わない事に全く意味はない C++だとライブラリ作る側でリソースの寿命まで面倒見れるようになるから、そういう意味でも本当に楽
リソース解放の関数呼べと仕様書に書いていても、それ守らないアホは必ず出てくるからね。
ただ、他言語含めたAPIとなると、マングリングの問題がでたり、スマポの管理が言語跨いで出来ない場合が多いから、APIだけCっぽくなってしまうこともよくある。 c/c++で書かれたプログラムが資産として、
たくさんあるのに、なぜこんなこと言うのか、わからない。
著者は、それらを捨てろと言いたいの？ >>「おぞましい」と言ったのは「悪い」ということではなく「畏敬の念を起こさ
>> せる怖さ」という意味だ。
そんな意味は無いよ。
C言語以前に、日本語を勉強しろ。 >>486
ひとつのオブジェクトに多スレッドからアクセスって嫌な予感しかしないんだがｗ
スレッド間通信はセーフティなキューとかを用意せにゃあかんやろ Ｒ言語で書いてある処理をＣに直せと言われたら、発狂しそう gnu cとclangのマングリングの差異は困るな
clangの対応がいつも遅いんだよな
あれ、今はんなことない？ >>474
Linusはいろんな意味でアレな人だから つーか、こんなマイナー言語、1年も経てば誰も覚えとらん。 バイブルである「プログラミング言語C++ 第4版」をトイレに置いて毎日少しずつ読んでる
何年も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言語を、日本のお馬鹿なソフト会社はその必要も無いアプリ開発に適用し、ポインターも解らぬＰＧにカーニハンの教科書を与えて開発させた。
その結果アプリは予想外のエラーを吐き続け、殆どのプロジェクトは終了しないまま頓挫した。
これにより、日本で何兆もの費用と、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につないでいるオチだろ
そりゃ同等に速いわ ■ このスレッドは過去ログ倉庫に格納されています
