【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/ いまヘベレケしてますんでマトモな返答は保証できません 今の王様はWeb、スマホのアプリケーションプログラミングだと思うけどなぁ…
この領域ではC/C++はお呼びでない ゼニカネを主軸に置くと、Ｃ関係は不要
しかし佳きＰＧを目指すなら「Ｃ言語」は必須
どのレベルで言ってるのか、人によって全く違うからね～ 不易流行
Ｃが不易
これは即席ゼニに成らないね
流行に流されて終わるＰＧに成らん方が身のため 機械語、アセンブラから入ったモンに言わせると「Ｃ言語」は高級言語
スタート言語が何処から入るかで言語マップが全く違ってきます >>848
C言語で
制御はわかるが
構造ってなんだい？ メモリが数KBや数十KBの頃はアセンブラ全盛
メモリが数百KBつかえるようになり、C言語が普及
メモリが10MB以上使えるようになってオブジェクト指向言語が普及
結局、開発効率と、メモリの無駄遣いをどれだけ許容できるかを天秤にかけてるだけ
Javaやスクリプト言語の普及はそれだけではなく、
CPUの性能向上でCPU資源を無駄遣いできるようになり、
高速実行よりも開発効率を優先することが重要になり普及
開発効率はソフトウェアの価格に直結する
数をたくさん販売できるパッケージ製品にはまだC++が使われることが多いが
特注のシステムには開発効率が悪すぎる スマホともなると、一番上のアプリと言われるユーザの目に触れるものから、
一番下の開発時のデバッグ用CPUすなわちICEあたりに、どれくらいどの言語が関与してるかも見ないとならない >>854
古いよ。
一昨年辺りから機械学習やIoTに移ってる。 >>863
MITは8年前にその辺をカバーする良質のライブラリがないschemeは捨ててpythonを使うことにした >>862
スマホじゃICEはなかなか使えないだろう
ユーザーの見えるところにJTAG端子が出ていないし リソースが限られた世界でＰＧできれば～今の無尽にリソースを駆使できる環境は天国
一種の「修行」な環境を各々が設定したらいい
「小は大を凌駕する」
これが電脳な世界観です Ｃ言語は樹木の「幹」
幹を知らずに「枝」「葉」は茂る事な一切無い
このイメージが理解できない人はＰＧ屋として大成しません
他業界に転身することを勧奨します >>858
おまえさん
ＰＧ向かん、他業界へ転身しましょう ＰＧってゼニカネから離れたところで趣味的に弄るのは楽しい
しかしカネが絡むと事は厄介なことになる
カネ＝不自由
天衣無縫な気分でＰＧ不能
こんな暗澹たる気分では宜しくない作文（ＰＧ）しかできません 小保方晴子 ＞＞＞ 前田敦子 菜々緒 長澤まさみ さとう珠緒
（一部抜粋）
小保方氏への女性批評は、『女が嫌いな女性タレントランキング』にそのまま当てはまる。
たとえば、「そこまで綺麗ではないのに、何でチヤホヤされるのか？」という意見で
『女が嫌いな女性タレントランキング』首位となった前田敦子。
「セクシーではなくて、媚を売るような感じが嫌」で上位の常連となった菜々緒や長澤まさみ。
そして、「ぶりっ子キャラは、ありえない」と、史上最も嫌われたさとう珠緒。
女性から見ると、小保方氏には、その全ての要素が当てはまるという。 >>868
もう遅いや
C言語で制御構造って教えて if とか for() とか break とかそういうの >>871
> >>868
> もう遅いや
>
> C言語で制御構造って教えて
横からすまんが、制御構造という言い方はある。Ｃ言語では言わないかもしれない。
ププグラミングで制御構造と言えば、
手続き型言語における、（順次構造）（選択構造）（反復構造）かな。
それぞれ、処理が現れた順番に実行する形式、 条件によって処理が分岐する形式、処理を繰り返し実行する形式。
かなり古い概念だな。
Ｃ言語で言えば、
if文 ２方向分岐
elseif文 多方向分岐
switch 多方向分岐
for 指定回数反復 （指定回数じゃない使い方も多いが）
while 前反転型不定回数反復
do while 後判定型不定回数反復
break 反復脱出
continue 反復スキップ
と言える。
要するに、条件分岐とループ。
ただ単に、順番に処理することもできる。
これは、機械語そのものの機能。メモリ管理もそう。
機械語では、ラベルを使って、メモリアドレスを示すが、Ｃの場合、変数名を使ってメモリアドレスを示す。mallocもある。
条件分岐で goto を使わせるとスパゲッティになるし、危ないことも起こるので、ifやswitch等で goto のとび先を自動で決定している。
とは言え、多重ループからの脱出には goto が便利なので使いもする。使うなら限定的でわかりやすい使い方ね。
これらが、機械語じゃなく、Ｃを使うメリット。
条件分岐が出来るかどうかは、他のマシン、例えば織機などからの対比。
メモリを使うかどうかは、専用マシン、例えば、そうだなー、テープを読み込んで、その指示に単に従う、というような超古典的なマシンとの対比。
ま、要するに、プログラム内蔵型計算機とはこういうものですよ、という古典的教科書での書き方。
メモリーにプログラムを置き、まあ、データも置き、開始ボタンを押せば、計算できる。ということ。
普通の四則演算の電卓と、関数電卓の差程度の話。 >>826
そういう曖昧で見落としやすくて間違いの元になりやすいこと自体が問題だと言っているのではないのかな
linuxのGPIOのある特殊なプロトコル向けのドライバでBIG endianのCPUを使って2ワード以上のI/Oを行った場合にだけ起きるバグを見つけたことあるけど
こんなの誰も問題が起きるなんて思っていないんだろうなぁってな
そもそも特殊な条件でないとテストもできないし環境を揃えても基本的なテストだけなら通ってしまう話でね
そういうのが言語処理系の曖昧さで発生したらとっても嫌じゃん >>859
「開発効率と、メモリの無駄遣いをどれだけ許容できるかを天秤にかけてる」
御意
まことにその通りです
シビアでクリティカルな環境下でＰＧ経験をしますと
現今のプログラム開発環境なんて天国クラスです >>247
Ｃ言語は自由度が高い
自由度が高い＝目的地に必ずしも到達しません
枠にはめられてないもん
野獣だな
これは愛人みたいなもんだな
スクリプト系は本妻です
ベル研の開発した通信系の言語
通信の本旨って「自由」にある
拘束を嫌がるのものです
馬で言えば「ジャジャ馬」
人で言えばどうぢようもない「不良児」
これがＣ言語の特長です 真の市場経済が拘束を嫌がるように「Ｃ」もそういうの大嫌い
ＢＤＳＭは、オラの世界ジャネーの・・・ お城の構造に例えると～
本丸、二の丸までは「Ｃ」とアセンブラ、機械語
三の丸以降・・・そして内堀、外堀はＣ言語を元に開発された
開発思想の明確な「オブジェクト言語」群
だから～Ｃにはセキュリティーは無い
内堀、外堀で守護さえないといけません
大脳本体に痛覚が無いように、
Ｃにも痛覚というセキュリティーが無い 戦場に「鎧」「兜」なしで素っ裸な「ストリート・キング」するのがＣ言語 日本のマイコンが滅びたのは
まともなCコンパイラを用意できなかった
のも要因の一つと考えている >>885
ARMのCコンパイラはまともだったからな >>886
比較したらどのあたりがどうまともなんでしょうか。 >>864
Pythonは、ただのラッパーですが？ 国産Cコンパイラもgccベースのは割と...いや、酷かったな。
OSもそうだけど、2000年代には見れる技術者がいなくなった。面子はいたけど技術水準が秀才レベルから天才レベルに引き上がって振り落とされた印象。 なら日本の天才育成システムが上手く行ってないだけじゃね >>885
ＡＲＭのことを全て知ってるわけではないけども、携帯端末向けによくできていた。
また、ヘンテコな工夫が随所に入ってる印象。
初期だと、条件分岐が常に命令の中に入っていて、パイプラインを長くした時に、遅延実行がうまくできる仕組みだった。
実行バイナリも小さいと思うし。
ＳＨもいい製品だったと思うが、パイプラインの段数を増やした時に、互換性が無くなったことをボヤいてた人がいた。
ＡＲＭはＪＡＶＡＶＭのアクセラレータなど、機能の追加増設もうまく当たったんじゃないかな。
ＳＨは国内のガラケーをかなり持ってたけども、ＡＲＭはＧＳＭを持っていた。
国内のガラケーメーカーが世界を支配するかアップル・グーグルの下請けになっていたらＡＲＭは無かったかもしれないけども、ＧＳＭの次にスマホが来た時は、ＡＲＭか。
ワット当たりの能力が高いとか、いろんな半導体メーカーにライセンスしたのも良かったんだろうね。
ＡＲＭはもう２０年以上になるのかな。インテル・ＭＩＰＳ・ＳＰＡＲＣ等と違うジャンル、携帯端末に特化してきたのが長く続いた理由なのだろう。
その意味では、ＳＨは不幸だったかもしれない。
ＡＲＭもいつ泡沫メーカーとして消えてもおかしくないような状況は常にある。今はものすごく注目されているけどもね。
例えば、スマホ向けには、バッテリーの持ち時間がユーザーの気になるところだし、処理能力についてもそう。
なので、ＡＲＭをある程度超える、ワット当たりの処理能力があり、最大処理能力がＡＲＭよりも上ならば、アップルは躊躇なくＡＲＭを切り捨てるだろうな。
なにしろ、自社のＯＳをいろんなアーキテクチャのＣＰＵで走らせることが出来るのだから。
グーグルも同様でしょう。自社サーバーをインテルからＰＯＷＥＲにしたり、ディープラーニング用のＴＰＵを作ったりしている。
今は、ＡＲＭを土台にしているけども、ＡＲＭのうち必要の無い機能、より高速化する機能を考えていくうちに、独自で作った方がいいとなるかもしれない。
出来るかどうかはさておき、ＡＲＭと同じ価格で、２０％低消費電力か２０％高速かを選べる競合が出たら乗り換えるんじゃないかな。 >>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#なんか遅くてカスみたいな言語だよ。 レス数が950を超えています。1000を超えると書き込みができなくなります。
