【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がいいのだが、C++となると首を傾げてしまう。
これは機械語から見た場合で、ヒューマン操作レベルから見ると>>1の通りC/C++は推薦しない。
取り敢えず動けばいいやと試作された他人のCのメンテを任された日にゃ・・・"(-""-)" >>420
そうなのか
出てきたときは、VBとc+の中間で絶対はやると思ったのになぁ おれ、CASL2しかやったことないんだけど、CとかC++とかやるべきなのかな? ハッカーだから悪党でないという論理等存在しえない
ハッカーにも悪党はいる、海外にいくならば経過を見る余地がある程度であり
正義を執行するための障害は何も存在しないだろう Cはなんでもできるんだから自分でセキュアなライブラリ作ればいいだけだろ
メモリ管理含めて 遊びで組み込みやってるから、そんなこと言わないでー >>417
フリーウェアじゃかなり普及したでしょ。
無くなったのは、開発元がグループウェアに注力するために、
撤退したのが原因。
マジギレしたチームリーダーが、ビル・ゲイツに直接交渉して、
チームまるごと雇ってもらってできたのがC# >>419
> 「初めてのC」タイトル本を見て手に取れなかった時代もあった
昔、今でもあるか、雑誌 エ/ロ、がアダルトコーナーに置いてあった。よく見たら、 I/O だった。 >>423
悪いハッカーはクラッカー
ハッカーと言ったらいい人しかいないイメージだったのにマスゴミが >>416
GCが「厳密な」管理かどうかという問題はあると思うけど
いちおうJavaでも7からtry-with-resources文が導入されたでしょ
スコープ脱出時にcloseしてくれる、Pythonのwithみたいなやつ
freeにあたるものを書かなくていいというんじゃ不足? >>429
ハッカーは良いものだが
現代における悪とは誤った情報を拡散することだ
虚偽の情報を拡散することで、弱者の権利を踏みにじってきた結果が
国際競争力が衰退した現在の日本の立ち位置だ
ハッカーが誤った情報でミスリードを行えば、それは悪党に他ならないということだ 日本経済の落日も明らかであり清算の時も着々と近づいているが
弱者の怒りの嵐が吹き荒れる、その時まで善でなくてはならない
それは絶対の基準であり、相対的に善等というものも存在しえない >>401
CだけとかC++だけをだすと、
「C++でも同じだろ」とか「なんでCは入ってないの?」とか突っ込まれるから。 >>401
C++といいつつC++になりきれないCソースが多いからじゃね? >>409
質の悪いコーダーでも、質の悪いコードを書くことができないようにプログラミング言語で
ガードするというのはよくあること。
型システムとか、生のポインタをプログラマに触らせないようにするとかもその一種。 >>418
CPUが管理するんじゃなくて、言語が管理の為の仕組みを提供すれば良いんじゃないかな。
たとえば、デストラクタでインスタンスが握ってるリソース(メモリ以外も)を開放するとかはよくやること。 >>435
それはずいぶんと昔のこと
今はスパコンでもメインフレームでも、Linuxが動いてるよ
パラレルなんとかは、C/C++で十分
インテルR Parallel Studio XE がいいかどうかは知らんが、FORTRANとC++は同列のサポートレベル
IBM Parallel Environmentでも、C, C++, Fortran。 >>439
言語がやればいい、のなら、そういうことをする便利なラッパを書けばいいんじゃないかな。
OSは特権モードで動くわけだけども、特殊なことをするのに、ユーザーモードじゃ不十分という意味? 昨日まではCは素晴らしい言語だと思っていた
でも今日一日で使うべきではないと悟った
コーダーに馬鹿が2人以上いるなら使ってはダメ クソがああああああああああああああああああ
あいつらの書いた2000行ゴミじゃねーかあああああああああああああああああああああ
メモリ破壊どんだけやらかしてるんだ死ねええええええええええええええええええええ
なんで俺がデバッガーやんねーといけねええええんだクソがああああああああああああ >>443
努力してコーダーになれ
もっともいいのはややこしい言語で書く機会をできるだけ減らすこと
触るのをやめること
これだけで幸せ度UP まぁ被害が2000行と少ないのがせめてもの救いやな >>444
俺は割とバグなくコード書けるで
>>445
時間がないんや・・・ どんな言語使っても、ダメコードを書く奴は普通に出るし
仕事となれば、尚更… >>447
それがC/C++であると致命傷になるんだよ
他の言語は3輪車に見えるかもしれないけど3輪車使っとけ C/C++って書き方おかしくね?すげぇ違和感ある
そもそもCとC++って別物だろ?
作者も違うし。
Cは好きだけどC++は嫌いって奴も多いだろ
例えばLinuxの開発者のライナスはC++が嫌い。
なのになんでC/C++っていうふうにひとくくりにするんだろ? >>449
昔からそういう書き方だから全然違和感ないね CとC++に分割しちゃうと
コミュニティも分断しちゃう感じがある
C++使うひとならCの話もおおよそ分かるのに。
なのでC/C++ってまとめるんじゃないのかな 今から20年以上前に俺がN88BASICやってた時はネイティブコード吐きだせるC言語に憧れたもんだけど
ここの住人はそのレベルで止まっているだけな気がしてきた >>452
機械語もあったでしょ。
Turbo Pascalと Turbo C はどっちが先だったか。
BASICコンパイラもあったよね。 最近、C++の勉強をやり始めて、ネットで調べながらpaizaのAランクは力技で取れた。
しかし、アプリを作ってみようとしたら、例外処理とか色々とつまづくところが出てきた。
やはり、あの1,300ページくらいあるビャーネ・ストラウストラップの本を読まないとダメなんかな?
アプリを作る上での標準的なエラー処理方法とか重い処理を並列で実行する方法を知りたいだけなんだが。 >>454
例えば関数のリターンをenumにして帰ってきた値で何のエラー起こってるか判断する
Assert自作して論理的矛盾みえたらメッセージボックスで関数名通知してそのまま無限Loopに突入させるとか
(´・ω・`)b CとC++を同じあつかいしてる
ところで1が何も解ってない
それにC++使うぐらいならJava、C#行くだろ普通 >>456
> それにC++使うぐらいならJava、C#行くだろ普通
用途によるだろ。
お前の想像する「普通」から外れたものには価値がないとでも思ってるのか? >>458
OSやハードウェアと密接な連携を取る必要がある、もしくは(相対的な)速度やフットプリントの軽さが求められる
Cで構築するには大きすぎる開発案件。
例えば組み込み機器などをターゲットとしたアプリケーション開発や、実行速度が求められるミドルウェアなど。 javaの開発元のワークステーションメーカーのサンがオラクルに吸収されて消滅するとは、あの頃は夢にも思わなかった。 >>460
なるほど
どれも経験ないわ
すまんかった。
Cでやれるんでね 流石に最近はよっぽど小規模な開発でもなければ、新規にCでやることは少なくなってきてるよ。 なるほど
こういう言い方にムカつく気持ちが解った。 CとC++を別物扱いしたい連中は、たぶんCすらまともに理解していない
んだと思う。算数と数学みたいな関係?長年Cを使っていて、こんなことが
できたらと思っていた機能が実装されているC++を知ってしまったら、C++
からCには戻れない。 >>456
どんな実務経験があるのか知らんが、知識も狭くて浅く、頭も悪そう。ガベ
コレありの言語は、リアルタイム性が要求される分野では使えない。
ガベコレ実行中は、自動ブレーキが効きませんとか。歩行者の検出が遅れて
人轢いちゃいました。テヘッとか。
それに、JavaやC#はROM化を前提としたプログラムの開発にはまず使えない。 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のみと思っているかもしれないけど、
スピードが要求される部分は、jniでつないで、
c/c++で書かれているんだよ。 使いこなせないロートルと、若年性痴ほう症のゆとりは見苦しいと、
50代専門卒が言ってみる。 つか、unique_ptrならそもそもオーバヘッド無いから、敢えて使わない事に全く意味はない C++だとライブラリ作る側でリソースの寿命まで面倒見れるようになるから、そういう意味でも本当に楽
リソース解放の関数呼べと仕様書に書いていても、それ守らないアホは必ず出てくるからね。
ただ、他言語含めたAPIとなると、マングリングの問題がでたり、スマポの管理が言語跨いで出来ない場合が多いから、APIだけCっぽくなってしまうこともよくある。 c/c++で書かれたプログラムが資産として、
たくさんあるのに、なぜこんなこと言うのか、わからない。
著者は、それらを捨てろと言いたいの? >>「おぞましい」と言ったのは「悪い」ということではなく「畏敬の念を起こさ
>> せる怖さ」という意味だ。
そんな意味は無いよ。
C言語以前に、日本語を勉強しろ。 >>486
ひとつのオブジェクトに多スレッドからアクセスって嫌な予感しかしないんだがw
スレッド間通信はセーフティなキューとかを用意せにゃあかんやろ R言語で書いてある処理をCに直せと言われたら、発狂しそう gnu cとclangのマングリングの差異は困るな
clangの対応がいつも遅いんだよな
あれ、今はんなことない? >>474
Linusはいろんな意味でアレな人だから つーか、こんなマイナー言語、1年も経てば誰も覚えとらん。 バイブルである「プログラミング言語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式は、文字列の長さが想定を越えると破綻する。 ■ このスレッドは過去ログ倉庫に格納されています