【IT】C/C++に死を [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
プログラミング言語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/ >>890
gcc、MSC、iccと並べると、icc。
gccが何故iccに並べないのかは知らないけども、コンパイル元とコンパイル結果が解っても、それに並べないだけの差があるんだろう。
ＣＰＵ作ってる最中にコンパイラも同時に作ってる連中に追いつけと言うのには無理があるかもしれないが、数か月で追いつけてもいい気はする。 >>889
AIも行きつくところはASICで、そうなるとC/C++もラッパーみたいなもんだと思うけどな そういうレベルじゃないよ
まず構造体が使えない
ちょっと凝った書き方するとバグる
ライブラリが動かないのにコードもない
開発してんだかコンパイラのバグ取ってんだが >>892
GoogleはOpenPowerとかRISC-VであからさまにARM潰ししてるし、
アポーはMacOSⅩをx86からARMへ移行する準備で、サブCPUとしてARMを採用するらしい
ちょっと最近の動向が少し違う >>896
googleの関わってるCPUは主にクラウド向けじゃん こういうスレでARMって聞くとARM本の方を思い浮かべてしまう >>899
普通、インテルかＡＭＤかで選択肢が止まる会社が多いが、その枠を越えてるよ。
ＭＳのよう過去との互換を極度に気にする会社もあれば、ソフトウエアを動かすプラットホーム、乗り換えはいつでも可能な会社は違う。
アップルが一番凄いと思うが、スマホだと、グーグル。グーグルは過去のバージョンを切り捨てることに躊躇がない。
パソコンだと、ＭＳ＝互換性重視、アップル＝最新の体験をしたい人だけどうぞ、だが。
スマホだと、アップル＝互換性重視・ハードウエアの修理可能な期限まではソフトはメンテし続ける。グーグル＝新しいＯＳ使えない人は早くハードを買い替えろ。
となっていて、グーグルはアップルよりも躊躇がないほど。
自社のソフトが動くハードをみんなが作ればいいんだよなのかな。
最初アンドロイドは、組み込み機器向けのＯＳで押して、いろいろ気にしてたが、今は、殿様だろう。 Cが死んだことにして
末端には富豪言語しか触らせない
で安泰だからな >>902
ARM = Annotated C++ Reference Manual
1990年代の注釈本。なつかしの必須アイテム。今となってはもう不要 >>904
まだ規格になってないtemplateが載っていたアグレッシブな本
当時のC++は特殊化にcppのマクロ展開を使っていた >>905
>cppのマクロ展開を使っていた
MFCのことか？(笑) >>906
何言ってるのかさっぱり分からん
>>905はC++にtemplateもなかったくらい昔の話だから
無理に参加しようとしなくていい C++じゃなくてCに+してなにかをーしたＣ＋－が必要だなｗ C--なら実際にあって
イギリスでは言語処理系実装に使われてた
MS Researchでも論文出てる
その後メタサキュラー実装のネイティブコンパイラが増えて下火になった https://www.indeed.com/jobtrends/q-java-q-python-q-ruby-q-c++-q-c%23-q-script-q-javascript.html
java, python, ruby, c++, c#, script, and javascript Job Trends
javascript（1%）のワード内にはscript（1.5%）も入ってるので、何でも系のスクリプト言語は0.5%と考えていい
Pythonの求人は（0.85%）なので、スクリプト言語で記載されたものを引き算すると0.35%がPythonメインの求人と考えられる
Pythonの求職者が、0.62%でさらに求職者数が増加するなら、実際にある求人を下回るどころか求職者にとっては短期・長期的に不利となる
求人と求職者のバランスが、求職者に有利なのはJavaとJavascriptとなる
Javaは求人は減っているが、求職者側のキーワードは割合は低く、需給バランスは需要が圧倒する
C++は集計不能なので、求職キーワードとしてつかう人間が少数すぎるか、求職者が圧倒的に仕事で使いたくない言語の可能性が高い（マイナーキーワードは集計外のため）
C#とRubyは需給が長期的に均衡しており、目先の利益でなく長期的な安定を目指すなら良いだろう
なぜ安定するかだが、供給側が安定しているということは、求職者が増えすぎて需給が反転する可能性が低いと理解できるからだ
CとGoについては、DやEやFといったキーワードが増えるため、cの入る単語、goの入る求人もヒット（go to officeのような一般的な文字もマッチ）している模様
そのため英単語にマッチするワードはトレンド集計の対象外となる Cは現在の多くの高級言語の基本になってるから勉強するには大変便利
ポインタさえなければ(´･ω･`) Rustは他言語で現場に入って勝手に使うしかないだろうね
結構混ぜ込む形でつかえたりする >求人と求職者のバランスが、求職者に有利なのはJavaとJavascriptとなる
>Javaは求人は減っているが、求職者側のキーワードは割合は低く、需給バランスは需要が圧倒する
JavaもJavascriptと文字がかぶるため、求人ヒット数が上がっている可能性もあるので注意
（JavaとJavascriptのトレンドがあまりにも似すぎている） あと、C++はねつ造くさいな
俺が前調べたときは、求人数に対して、ユーザー数が多すぎて、
非常におすすめできない言語だったと思う
Cがアセンブラとか言ってるのを聞くと違和感がある。
アセンブラやったことない人間がそう言ってるんじゃねえかって思う。
普及するようなものではない
アレはコンパイラ屋が最適に使えばよいことだ Cのmain関数すら呼ばれてないマイコンの起動直後にいろいろ弄ったりするくらいしか使わないなーアセンブラは
SIMDやコプロのコードも大抵Cで書けるように関数用意してくれてるからね
でもデバッグ時にディスアセンブルされたコード見るから自然に覚えるでしょみんな >>928
そりゃCがアセンブラをほぼ駆逐したんだから
低レベル記述可能言語として
>>922
ポインタなければそれは不可能だった >>931
Cは低レベルの記述は欠陥品だけどな
できないことが多すぎて話にならん
それっぽいことのうち一部の事ができることもあるという程度
勘違いする奴多数なので今となっては有害でしかない visualstudioにパイソンgui入れてくれ >>932
現実を見ろ
自分がどんだけ馬鹿かよく分かるだろ >>933
まずironpythonのpython3化を先に… >>935
現実？
Cで逆立ちしてもできない事とか、出来ても恐ろしく不効率になる所ではアセンブラ使っているよ
バカには見えないかもしれないけどな >>935
というか
お前「Cでできないこと」が想像つかないんじゃないか？
アトミックな処理とか
CPUのモードを変更する処理とか
スタックフレームを直接操作する処理とか
この手の処理はデバッガでは使うぞ >>922
Cから、ポインタを除いたら、即、要らない言語になる。 >>938
プロセッサ固有の処理を入れなかったからこそ、普及したんだが。
もしかして、全てのCPUがモードを持ってると思ってる？
> スタックフレームを直接操作する処理とか
あえて操作できないようにすることで開発効率を上げていることに気付こう。 なんでもできることは必ずしもいいことじゃないんだよ
そもそもC言語はアセンブリ言語(もしくはインラインアセンブリ)
と組み合わせて使われることを想定しているんだから
アセンブリ言語でできることがC言語ではできないと文句言うのは不毛 >>943
何を言っている
Cではアセンブリ言語の代わりにはならないし駆逐もできない
それだけ >>944
もとは、Cに「欠陥」があると言い出した >>932 が発端なわけだが、
別に欠陥があるわけじゃない。
CPUアーキテクチャに依存する部分は、
アセンブリ言語で書くのが最も理にかなっているから、
最初からコンパイラがそんな部分に対応する必要はないということ。 >>943
>そもそもC言語はアセンブリ言語(もしくはインラインアセンブリ)
>と組み合わせて使われることを想定しているんだから
そういう立場ならば「Ｃのポインタで低レベルの操作ができる」なんていうのは
実は中途半端なことしかできないゴミクズ機能でむしろ有害な仕様だ、という
見方するほうが自然で、最近は実際にそういう立場をとる人も多い
それで>>1の話に戻るってわけだ ちと別回線から書いているが944と同一人物だ。
>>946
だから「今となっては欠陥」という立場をとる人も最近は増えているという話 >>914
まちがっている。
++がだぶっているだけだ。
C#なんか遅くてカスみたいな言語だよ。 >>947
なるほど。一理あるな。
しかし、他の言語でC、C++のゴミ機能が
出来るものがあるのか？
C,C++の機能をへちって、ゴミ機能だけに
するべきかな？ >>927
そうかもしれない。
アセンブラは素晴らしいが、量がかけない。
デバッグも面倒だ。何しろ、出来ないことが
ないので、めちゃくちゃ出来る。
何年もたってバージョンアップするときは
泣くね。
出来たらC言語で書きたいよ。
スピードが要求されないなら。 >>926
C++はかなり難しいね。
しかし、それも静的解決が出来る世界での
話でだと思う。
たかがスコープ三層の静的世界でこの
難しさに悩む人間の知性の限界を疑う。
動的な言語はまた、別の意味で難しい。
本当に開放された変数の動的解決が
出来る言語が登場するとどうなるのであろうか？
新しい言語世界の誕生に追随するプログラマと
デザイナが躍進する世界がくるのか？
オブジェクト指向の次のパラダイムかもしれない。 でも Java でも C# でも
参照型をきちんと理解するのには
ポインタの考え方が必要な気もする Rust Evangelism Strike Force >>944
ツマラン喧嘩はしなさんな
ミットモナイわ～ Ｃは、本妻と云うよりは俺が最も心を通じ許しあえる愛人
アセンブラが愛人の連れ子かな～ >>944
いったい何に反論しているんだ？
C言語がアセンブリ言語の代わりになるとか
アセンブリ言語を駆逐しようとか
そんなことは一言も書いてないのだが。 >>951
C++もCからしたら遅くてカスみたいな言語だろ 俺とＣと云う愛人は直接の血縁関係に無い
他人だけど本妻よりも深く愛し逢っている
その連れ子ですから愛人未満の範囲内で大切にしましょう だれか、パースペクティブ（見取り図・概観図）を描いてくれんか？
Ｃ
Ｃ+
Ｃ++
Ｃ＃
アセンブラ
このそれぞれの言語が最も得意とする領域と不得手な領域は何か？
制御系とか、通信系とか・・・いろいろあるでしょ？
全部、オールマイティにＰＧなんかできるわけないがな
だから、その業務に最適化された人工言語が発明されます Rust Evangelism Strike ForceはC/C++の代替とされるD言語、golangへの
ネガティブキャンペーンを揶揄している
類似言語のHaskell/OCamlの開発者がRustのマーケティングのコアを担っているため
Haskell/OCamlのマーケティング文化が受け継がれた OSを全部C以外で作らないと無くならないんじゃね。 本当の戦場はOSとアプリの中間だと思うけどなぁ
アプリの最適化とか、ドライバ せいぜいカーネルモジュール
まずはそこで、C/C++をどれだけ削れるかだ ポインタが、バグとセキュリティ・ホールの多くの原因を作っているから、
ポインタの使用が前提の、抽象度が低い言語の使用を止めようという、昔ながらの話題。
例えば、早い処理系を作るのにポインタは欠かせないし、
安価なハードウェアで動作する組み込み系のアプリも無くならないから、
C/C++は無くならないよ。
同じ話題を何度も蒸し返すなよ。ちょっとは学習したら良いのに。 C/C++並かそれ以上の高速化を実現できるプログラミング言語の候補って何でしょう？ >>971
なぜC/C++が速いのかを考えればいいんじゃね？ >>971
O'camlは不要なら計算自体を辞める・省略するレベルの最適化をやっているからC/C++より早くなる。
というか、いくつかベンチマークでは実際C/C++を上回っている Rust攻撃部隊（Strikeforce）はHaskell攻撃部隊出身と揶揄されている
https://news.ycombinator.com/item?id=13759706
hkmurakami 160 days ago [-]
This is amazing.
"The Rust Evangelism Strikeforce" is particularly brilliant.
clock_tower 160 days ago [-]
I'm still breathing a sigh of relief that it's no longer the Haskell Evangelism Strikeforce. People can preach Rust all they like, but Haskell scared me.
pvg 160 days ago [-]
They aren't that dissimilar. Both promote ambitious languages in which lofty ideals somewhat get in the way of convenience, practicality and available brain capacity.
Both consist, for the most part, of disturbingly enthusiastic but generally friendly disciples. They want you to believe, to suffer meaningfully, to achieve one-ness with
the borrow checker, to be (or Maybe) The Monad.
They're not, say, supercilious lispers who have guarded the bucket of unvarnished truth since 1958 or rubyists
promising a path to happiness in this life (and also something about monkeys). cはまだしもc++は人間が扱える言語じゃないよ
自分で作ったものならまだしも、人の作ったものを解析するのが困難
１回作ったら、その後修正しないってソフトなら問題ないけど、何度も修正するようなソフトだと問題なんじゃないか ucaetano 160 days ago [-]
Does it use convolutional recursive space invariant artificial deep neural networks?
sidlls 160 days ago [-]
Yes, implemented in Rust.
hodgesrm 160 days ago [-]
Except that we don't really have time to implement it because we're too busy posting to the resulting Rust vs. Golang foodfight.
yumaikas 160 days ago [-]
And this Gopher would rather build stuff than argue about Rust. >>975
Cと比較したらC++の方が見やすいと思うけどなぁ。 hodgesrm 160 days ago [-]
"Rust対Golangの早食い競争結果の投稿に忙しすぎて、我らは（Rustで◯◯を）実装する時間が本当にないのだ。"
tyingq 160 days ago [-]
"Rust伝道ストライクフォースは出撃するも、抵抗にあったのであった。"
K0SM0S 160 days ago [-]
実用的な価値や興味深い結果や有用な方法論を持たない履歴書作成エクササイズ。
Hackernewsは悪い設計のプログラムをできるだけ早く実行するソフトウェアの
メリットについて議論し、Rust伝道師攻撃部隊は、人々が"高速な"コードに
ついて話しをするので、(Hackernewsに)関与しないという戦術的決定を下したのであった。 >>975
WebKit等、膨大な資産が現役なんだが?
他にいい言語あるならとっくに駆逐されてるはず アセンブリの一つ上の水準の言語がC言語で間にあってる……と同時にそれ以外は不要らしい
C言語以上に増やしたらその水準の記述がさらに面倒になる
要するに面倒事は一つでいいしその言語だけに押し込めときゃいい Ｃ言語はアセンブリ言語の代わりというだけやからな。
何でもできる以上、安全に組むのに失敗したら、どんな問題でも起こるのは当然。
言わば自動航法の無い飛行機操縦みたいなものだ。
「何でもできる」ことがそもそも不要なら、他の開発環境の方がよろしい。 「型」は制約を加えることにより生産性を上げるための概念
あまり自由過ぎるというのもよくないんだよ 最近はコンパイラやチェッカーが賢くて色々教えてくれるけどね >>985
それも1970年代に関数型言語がREPLでやっていたことを
最近のIDEがある環境でも同じことができるように再整備しているだけだと思うけどな 変数に型を設定して受け入れるデータに制限を与える主義と
型はデータに付随する属性であって
入れ物たる変数には型を設定せず
全てのデータを受け入れるべきって主義と
二派あるからな
後者は動的に処理しないと実現出来ないからトロくなりがちだけど >>986
今の開発環境の元祖はXerox PARCのsmalltalk-80やInterLisp-Dだよ
70年代末も掛かるけど本格的には80年代入ってから
70年代最先端のMacLisp環境は15年くらい前のEmacsと大差ない
UI上の支援はあるが言語知識に基づいた支援は少ない
MacLispは今はエミュがあるから動かしてみれば分かる >>987
学生が大学の演習で作る簡易的な処理系ならそう言えるかもしれないけど
今はJITやるから速度面の差はほとんどない
90年代初めのSelfの研究で広く知られるようになった
初期のJavascript JITの論文ほとんど全てに
この論文が参考文献に上がってる >>988
StandardじゃないMLが一応ぎり70年代（1978か1979）だったはず。 アメリカの大学では就職率を上げるために学部・専攻と関係のある産業界でシェアのある言語を勉強するよう奨励するんだが
日本の大学は自由だな
http://www.pllab.riec.tohoku.ac.jp/slides/jssst2013Taikai.pdf
本当のプログラマは ML を使うようになる - か？
(1992 年 ソフトウエア科学会大会チュートリアル)
産業界の一般的な反応？
.... ＜関心がない＞
今必要なものは新奇な言語ではなく，サービスやビッグデータ基盤 レス数が950を超えています。1000を超えると書き込みができなくなります。
