【IT】C/C++に死を [無断転載禁止]©2ch.net
レス数が900を超えています。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/ >>803
日本語のコミュニティで、英語で書くとか、ないでしょ。
英語のコミュニティで、日本語で書くとかもないなー。
英語コンプレックスの奴多いんだな。どんな仕事してるんだろ。 >>806
> あれ？ID:I7yLCD5yはもう出てこないの？
楽しい？
まあ、楽しいなら何よりだ。
どんなプログラミング言語を使ってるか書いてごらん。２－３個でもいいよ。 >>817
nullPointerの実装以外にも、bitfieldの順番とかstructのpaddingとか変数のalignmentとか
処理系依存な箇所はたくさんあるんだけど。
C言語はそういう、便利だったり速かったりするけど処理系依存なコードを書くことを認めてる言語なんだし。 >>823
日本人メインテナがいることも知らない無知な奴だからスルーで >>826
そうですねぇ。
ビットのエンディアンが問題になったこともありましたね。
http://www.takeoka.org/~take/cpu/endian/bit-endian.html
メモリー上に何をどう置くのかも、結局はハードウエア依存の問題。最適化した場合は。
ＤＤＲ４のメモリーは、デュアルチャンネルで、１２８ビットなのかな。
メモリーバンドの効率的な利用を考えると、バイトでギッチリ詰めるよりは、
メモリーのアライメントに沿って、１回の転送で済むように配置した方がお得、という話。
そのうちに、１２８ビットが５１２ビットになるらしいです。もっと増えるかも。 Ｃ言語は懐が深い
あらゆるものを受け入れるだけの器量がある OSS関係は日本のPGのボランティアでかなり支えられてます
Linux系のDebian、Redhat、Vineとあるが
それぞれ、欧州、米州、日本で宜しく使われている
だからＶｉｎｅで組んだ方が日本用途としては使い勝手が良い
これはあくまでも個人的観相であるが・・・ 移植性とか考える必要はあるが、何も努力しなくても、そのままコンパイル実行可能を
保証しろというのは、やりすぎじゃないかと思う。 >>602
アセンブル ： 組み立てる
アセンブリ ： 中間部品程度の意味
アセンブラ ： 処理系、アセンブリ言語の俗称
アセンブリ言語 ： 言語
ふつうIT系では、「アセンブラ」と呼んでおいたほうが、
周囲との摩擦が少ない PC初期のころ、タイトルが「機械語～」で
中身がアセンブリ言語の初歩とアセンブル方法の解説ってのが多かったな
アーキテクチャ入門書かと思って開いてガッカリ >>812
当時、なんで今頃真空管なんか使ってるんだと悩んだ西側がひねくり出した答えがEMP対策な
で、真相は当時の東側ではまだ真空管のほうが普通に使われて流通してたから
今でも秋葉の部品屋にいくとソ連製の真空管が大量に売られている >>832
いやアセンブリだろ
普通
アセンブラっていったら通じないことはないまでも誤解を招きかねないし突っ込まれる >>834
ジャック品ってオモロイ部材に出会えました
真空管回路は単純明快
１つの素子から、どんな回路設計ができるかな「パズル」心が揺れ動く
いま、これが無い
アナログは～鈍重だが非常に分かり易い反応します Ｃ言語は、英語です
ＰＧの国際語
趣味でいいから、きちんと領得して損は無い
通信、制御の「王様」なポジションにある
スクリプト言語はＰＧ用では無い
自由度が高い、ここに意味がある 送信機の方簡単に構成可能
受信機の方が格段にテクを要します
発話よりも受話能力の方が格段に高級つー事と同値 自閉症な子って受話能力はピカイチ
発話能力は意図的に絞ってる
聴きはするが送信機能を落してる バカどもはこの逆をします
受信能力は非常にプアー
何もわからずギャーギャ―ギャギャー騒がしい
黙るという作法を知りません
ひたすら「ギャーギャ―ギャギャー」五月蠅い
ここに理念も思想も無い「街宣車」 いまの日本の風景は、五月蠅い送話しかない
ココロもなければ、気持ちもなにもない
ひたすら、五月蠅いだけのクズ 配列のインデックスチェックを無駄に繰り返すことは避けたい
そうなるとインデックスが変なところに指すことがないように、コードを書く人が注意することになる
それなら別にC/C++でいいよ
そうなりそう >>844
foreach的なもの使えばいいだけだからCに拘る必要なし >>536
「はじめてのC
さいごまでC」
シーシーオシッコ
やはり、ヴァイタミン「Ｃ」が足りないようです >>156
御意・・・
その通り
Ｃ言語って忍者と云うか蛞蝓というか～
明確な形が無い
♀とオマンコしてるんだが
オマンコの情況が良く分からん
普通はオマンコは定期的なサイクルで締まる・緩むですけど
Ｃ言語♀の万個は、挙動不審
ＰＧ屋してるの、この怪しいマンコをどのように調教しようかという
途方もない欲望に捉われます >>156
「制御構造とメモリ管理」
これに尽きる、頂きました >>830
Vineってw
いつからLinux使ってないんだ? >>849
１０年は仕事では弄って無い
ブドウ球菌にヤラレタみたいｗ
この業界から脚を洗いました いまヘベレケしてますんでマトモな返答は保証できません 今の王様は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は現在の多くの高級言語の基本になってるから勉強するには大変便利
ポインタさえなければ(´･ω･`) レス数が900を超えています。1000を超えると表示できなくなるよ。
