◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/bizplus/1500273631/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
プログラミング言語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/ 早いってだけではある
Rust は、Cの代わりにはなれん。
組み込みだと未だにCかよくてC++なんだよな
セキュリティホールを気にするならCはやめた方が良いな
昔からpascalの方が筋の通っている言語な感じで好きだな。Cは嫌い。
原始言語はいらない
,;:⌒:;,
カーニハン アンド リッチーの本は本当に入門用として優れてるのか疑問。
>>15 あの時代に、学ぼうっていう人向けの解説書けんデファクト仕様書
コイツの頭の中ではBOFとポンターだけがセキュリティリスクらしい
pythonとJAVAのSwiftとPHPくらいだな
Ｋ＆Ｒなんて古典的な文法で読みづらいゴミクズ。ＡＮＳＩだろ。
>>12 ただ、pascalはもう実用してないんだよな
学生の学習用言語として残ってるだけで
手塚σ
みんなでLISPを使えば幸せになれるよ
>>15 入門ではないけど、できてるつもりの人が読むと目から鱗な本。
,;:⌒:;,
【IT】PythonがJavaに迫る勢い - 7月の開発言語ランキング [無断転載禁止]©2ch.net
http://egg.2ch.net/test/read.cgi/bizplus/1499562234/ セキュリティホール対策って言っても
c/c++は永遠だよ。
>>10 日本は新しいことに恐怖心があるからね
そのくせに非セキュアなコードを放置する
>>36 いかにも日本的思考だなぁ
新しいものが次々と出てきても知らんぷりなんだよな
>>36 永遠はないよ。
新しいチップと合わせてその時代にふさわしいコードが採用される。
>>38 組込系や制御系で使えて、ネイティブなコードを書ける言語を教えて。
C++は死んでるも同然だろ
sine:（enter
>>18 ENTER＞
C//33
://C.
>>42 横だが、ネイティブはアセンブラでしょ
C言語でもともとネイティブはないよ
>>39 でも、今でもC/C++は使われているよ。
まず、組込系や制御系。
それに、windowsだって、スピードが要求される部分はc/c++。
ドライバーもC/C++。
C#やjavaは遅い。
セキュリティホールはPGM言語を変えれば無くなるんだから
>>50 情弱だな。
インタープリター以外はネイティブでしょw
実際はCでは無理なものもたくさんある。
Cはスタックポインタに依存する言語
スタックが使えないPICマイコンは向かない。
>>51 C#やjavaは、ネイティブじゃないよ。
>>51 今の電気製品で、PICマイコン使っているのもどれくらいあるの？
>>54 馬鹿か！
非効率なんだよ。
高級源は言語単位で作られているので
必要としない処理まではいる。
結果的には無駄が多く遅くなる。
組み込みは特にそう。
ある程度本体スペックた高くパソコンやスマホもしくはOSというもので
動かせる類はC言語等でいいかもしれないが
少ないメモリーでつくる類は満足のいくものは作れない。
そんなときこそアセンブラ
情弱考える最小単位はC言語にある命令そのもの
C言語はWindows丸ごとなくなるだろうよ。
>>57 30年前に担当していた電機製品は、アセンブラで開発していた。
でも、それ以降、組込系もC言語、C＋＋で開発できるようになったけど。
未だに、アセンブラ使っているの？
>>10 経験上組み込みだからってCしか知らないエンジニアは２流
簡単なツールでも何でもCで作りやがる 無駄にオプション増やすくせにgetopt(3)も知らない
better C選手権はgolangの優勝で幕を閉じたと聞いたが
うるせえよ馬鹿、おまえがいるから世の中悪いんだよwww.ac.jp//html
高級言語はアセンブラーのpre-Processor。
>>68 うちの会社でもやっているんだが
C++の学習はC++11/14でやるのがいいよ。
古いスタイルへの対応は慣れてからでいい。
海外での反応は様々だが、最大の問題点は開発者が少数のグループで構成されていること、導入するシステムが少なすぎるいうこと
C++も進化してるので、重要なソフトウェア（OS、コンパイラー等）で採用されないと、Rustが死ぬこともあり得ること
利点としては一旦採用されたならスマホやWebスクリプトのように言語が2年単位で切り替わることがないこと
https://techcrunch.com/2017/07/16/death-to-c/ コメント欄より
Issahar Gourfinkel
One more C programming paranoia article.
I remember how they try to convince me the same on release of vb6.
David Lodge · Plant Technician at Green Teams, Inc.
Sure, c++ is losing market share in new projects; As programming advances, why do we need such a powerful low level like c++?;
I think there are easier py-languages to py-use;
Brian Hart
Hmm if C is so unsafe I wonder why its used for flight termination for Nasa and the Military.
Michael Hofmann
(My completely personal opinion)
I agree with the notion that safe, secure, large-scale software cannot be easily built in C. Plain C is an outdated, deprecated language.
But the author is conflating C and C++. C++, as the author (and unfortunately so many others) might not be aware of, is actually a different language.
And there is no such language as "C/C++", by the way.
Modern C++ code is several orders of magnitude safer then corresponding C code, and, if applied correctly, modern C++ makes most memory leaks,
buffer overflows, or other security related issues a thing of the past. If anything, death should come to C code and ancient C++ code,
but modern C++ (11/14/17) should be pushed and taught.
And about using Rust at scale: very stupid idea. Rust is an new, unproven language currently supported by a small group of people, and that
hasn't stood any serious test of time or gained any reasonable market share yet. With (modern) C++ in existence, I see no particular raison d'etre for Rust.
>>63 ハードウェア的には３つ存在する。
０か１か繋がってないか
つっても組み込みなんてC系なかったら成り立たんレベルだろ
>>79 物理的に壊れるの想定せずに組んでひどい目にあったｗ
車に例えると
>>77 そもそもC/C++はどっちも初心者お断り言語だろ
かつて処理きついところとか局所的にアセンブラで書いてたろ
あの立ち位置が今のC/C++だ
>>80 組み込み系で使う理由は楽するためです。
どうでもいい部分をC言語で作ります
クリティカルな部分はインラインアセンブラで記述します。
Cがメインではなく楽するために作っているので
他の方が公立的であるなら他に移るだけだと思います。
言語の具体性が高いほど複雑になるからな
適材適所
www.ac.jp//html/
https:// >>1 海外の反応で面白いと感じたのは、この類の記事は頻繁に掲載されるが、
記事の通り言語を切り替えたら、歳を重ねても何の技術も身につかないまま終っていたというコメント
Java、C#やVB6も同じ記事を頻繁に飛ばしていたらしいが殺したというより、各言語がふさわしい居場所と活躍の場を見つけたという方が正しい
Rustの居場所がC言語を殺さないと見つけられないとすると、C言語との戦いに勝てないとRustが殺される（開発者が解散する）憂き目にあいそうだな
https://techcrunch.com/2017/07/16/death-to-c/ コメント欄より
Michael Wenk · The Ohio State University
So... C is dead, long live C, and go with Rust. Okay. Except the minor fact that these articles come out regularly.
If I switched language every time I read something like this, I would have no expertise in anything.
C is 45 years old, so it would be sad if it really was the best thing out there these days. However, that doesn't mean
rewrite, excuse me, refactor every bit of C code into the language of the day.
I implore any decision maker that reads this article to reconsider. If you have C expertise (or Java, or any other
language on the same line), then you will almost always have an easier time using that expertise than trying to
grow some in the new language. If you're worried about such statements that X thing is easier in the new language
then don't be. Its almost always just as easier for a developer to mess up X in the new language as it is in the old.
There are places to use new languages. Just not super mission critical things. I can guarentee you one thing, people
like the author won't be there when you're mission critical software goes bump in the night.
>>36 > C/C++以外でネイティブなコードは書けないよ。
もうちょっと勉強しよう。
>>1 >学生に標準Cライブラリー関数を一から書き直させることから始まる
これ学生にやらせるにはいい課題だな
Cは残って欲しい（し、多分残るでしょ）が、C++はもうオワコンだろ、正直。
何に使うんだ？奇妙・キテレツな進化をしてるC++なんて
使うとしたら「ベターC」か。stringとかlistとか便利だし
でもそうするとSTL必須になるし、ダークサイド一直線w
OSやデバイスドライバ、基本ライブラリはC言語じゃないと書けない
>>1 なんで、死なにゃならんの？
ほっといてくれよ。
rustはいいんだけど、C++でさえ拒否反応起こす奴が多い現状では普及は難しいだろうな
>>93 確かに、ベターCとして使うことの方が多い。
C++の入門書を見ると、やれクラスだ継承だポリモーフィズムとなるが、実際のところあまり使わなない。
継承はどうしてもクラスの包含では解決できないときに渋々使う感じ。
なので、C++はstringとかSTLのために使ってる。配列のインデックス管理とか面倒だからね。
あと、どこでも変数宣言ができるのも地味だけど便利。
ハードウェア設計をやってると、C以外の高級言語なんて使う機会は皆無。
>>9 今はスゴいHの時代、状態に影響を与えないのがもてはやされてるんだぜ
>>100 それでいいんだよ。C++の思想は「いろいろ用意したから好きなの使え」。
別にオブジェクト指向やる必要もない。その実用主義がC++のいいところ。
>>79 あと、0か1かランダムブレる（不定）という状態もあるぞ？
まあ、接続してないってのはハードウェア的には不定なんだがな
>>1 Cで十分
Cでセキュリティホールとか、
メモリーリークとか、チャンチャラおかしい
初心者かよwww
お子ちゃまは、オッパイ飲んで寝んねしてな
もうこいつも阿呆なんだから日本語で書けるようにしろよ
>>105 ポインター使った経験ないど素人だな、お前は（笑）
Rust最大の問題は生産性の低さだと聞いたが…
C++は怪物言語だけど、一番万能言語に近くもあるね
ﾒﾓﾘｰﾘｰｸはｽﾚｯﾄﾞ関連でも起きるんだよな。w
Cはなんでもｷｬｽﾄできるから危ないといわれ、
まあ、言語はなんでもいいんだけどな。
C++のﾊﾞｰｼﾞｮﾝの新しいのは、便利といえば便利だが、
高速だしメモリをいじったりするのには代替が無いだろ
cでもcppでもいいけど、昔ながらの職人コード書くのはやめてほしい。
ネイティブ開発ならOCamlでやればいい
カーネルをほかの言語で書き直すのは現実的じゃないよな
昔からあるOSや組み込みソフトやらミドルウェアはCでもいいだろうて
イメージだけだけど、
https://techcrunch.com/2017/07/16/death-to-c/ コメント欄より
Seth Anderson
$ mv <This Article> /dev/null
$ mv Rust /dev/null
or
$ cp "Death to C, ++".txt "Why can't everything just be in Node.js and Windows".txt
$ whoami
Windows desktopper
TrimﾒｿｯﾄﾞをCで書くとすごく長くなるんだけど、
>>93 なんでSTLがダークサイドなんだ？
俺なんかboostすら使いまくりなのに
組み込みでんなの使えない？知るかよw
いまじゃBIOSでしか使われていないらしいFORTHとか、
SINE:/｛1｝
>>54 今はJavaもネイティブコンパイルされて動くんよ。
知り合いの東大生はほとんど自作で標準ライブラリをほとんどincludeしてなかったな。
>>132 FORTH ならアセンブラ並みに高速になるけどな。
さすがにあの文法はなぁ。文法と呼べるかすら微妙だしな。
俺は好きなんだが。
WEBとJAVAにjavascriptの組み合わせこそ死が必要
ネットワークを無効化するプログラムを書けば良いんですか
C = Abstracted Macro Assembler
セキュリティーホールの発生の責任を、コンピュータ言語に負わせるのは無理がある。
>>1 糞スレたてんな。
15年も前に終わった話をいまさら何を言っているのか。
まあ、これはアレだな
>>2 それは違う
cでできることに蓋をして単純化したのが、その他の言語
>>108 慣れの問題ではあるんだけどね。
C/C++の感覚でデータ構造とか考えてるとコンパイルすら通らないのでイライラする。
>>112 複数人での大規模開発をCでやるのも結構無理がある。
C#はIDEのお陰で便利だが.Netをインストールしてくれる鯖が余りない
これからはC#でUNITYの時代だろ
C と比べて高機能なこと
0101130111000031101301010103010030103
PICでもC言語使えるじゃん
言語以前にコンピュータシステムや通信プロトコルを理解していないSEが多すぎる
ミジカビの
今じゃクラス機能が入ったりPHP7が出てきたりマシンの性能が上がってPHPの開発が増えてるぞ
>>160 PHPから入ったから少しずつわかってきたが完全には理解してないなｗ
PCスペックは最近のWEBやアプリ開発ではローカルに本番と同じ環境を構築するからある程度のものは必要になる
03103103000010310103011000000130000000000013101
1001031011010101000010310100000000000001
>>163 https://clearedjobs.net/job/principal-real-time-embedded-software-engineer-e05-e06-tucson-arizona-395808 今はC++とAdaが共存
U.S. Citizenship is required
Minimum of 8 years of experience in an embedded real-time setting
Experience using C / C++
Experience developing, testing and integrating real-time software
Experience using embedded RTOSs (e.g. VxWorks, Integrity)
Experience with software/hardware/firmware integration
もし幼稚語ならコンピュータがバカにするなって
CとかC++とか、あんな変態言語、いまさら使う気も起きねえわ。
>>14 これはハゲしくハゲ
こんなハゲな意見にハゲしたのは久々
最後にもう一度、ハゲしく同意
>>94 gccだってc++で書かれるようになったのにそれは無いだろ
>>153 AWSとかAzureとか使えばいいじゃないの
Rustは置き換えコストと学習コスト、継続性、可搬性を考慮して、
Ｃ＃は逆アセンブルされて技術が漏れやすいからな。
Pythonや Javaでドライバは書けない。
ポインタとかバグの温床だしガベージコレクションない言語はもう使いたくねぇわ
そういうレイアーに無縁なんだろうね
>>181 ガベージコレクションと言語は 関係ないけどな。
ｷｬﾒﾛﾝ前首相が、監視できないwebはあってはならないとか言ってから、
量子ｺﾝﾋﾟｭｰﾀｰにも何らかのﾊﾞｯｸﾄﾞｱが仕込まれる可能性がある。
>バッファーオーバーフローや宙ぶらりんのポインターのために壊滅的セキュリティーホールが生まれる事態
ﾒﾃﾞｨｱからｲﾒｰｼﾞを吸い出せないｹﾞｰﾑ機というのも
ｾｷｭｱ系のAPIやらCRT関数は、範囲ﾁｪｯｸを中で行っているから、
>>96 やっぱりそうか。１見ておかしいなぁと思ってた。注目集めたいだけだったのかな。
>>132 誰かが、システム記述言語Ｃ
ＯＳを書けるのはＣだけ
と騒いだから
アセンブラに辟易してた時に降臨したから
無料で使えるUNIXもどきがＣで書かれてたから
>>36 RAMのサイズが2kBとかだとＣ以外は考えられない
あとはＡＳＭくらいだ
>>64 ゲーム屋にいたすごい昔の話
仕事変えてだいぶ経つけど懐かしくなって最近はアンドロイドでJAVA勉強してるよ
Microsoft製を使うメリットはないだろ
世界はCとC++が支えている
>>15 プログラミングの経験が全くない人には向かないかもしれない。
しかし他の言語やアセンブラの経験があれば大変優れた入門書だと思う。
俺はあまりの分かり易さに衝撃を受けた。それでいて言語仕様の非常に細かい
ところまで網羅されている。
他のプログラミング言語の入門書もあんな風に書かれていたら楽なのにと思う。
C++は、
>>96 C以外でも書けるけど。
何処かで読んだ内容をただ丸暗記してるだけで、
なんでOSを書ける言語とそうでない言語があるのかとか考えたことないでしょ。
C#＋P/Invoke＋unsafe＋fixed＝最強
なんで組込み系は馬鹿にされるのか
この手のエバァンジェリスト達は、手法を誤ってる
このスレで言うところのアセンブラってPICとかSHとかARM7TDMIとか？
ppなんてエンジニアから嫌われてるもんなのに擁護多いなwwそんなに恐れてんのか？ppより学習コスト低いんだぜ？
EF
セキュリティ対策を施した新言語
この速さだからいうがRenesasのpinfuncは嫌いだ。
>>205 Cortexは知らんが、
ARMの初期のJITコンパイラ作ってた人はアセンブラで書いてたよ。
>>36 AplleがなぜLLVMを作ったのか調べてみよう
Cは組み込み、あるいはライブラリ
>>212 ARMでいうと、ARM7ぐらいまではアセンブリ言語を覚えるのもそれほど苦ではないし。
従来の8080/8086とか6809とかのノリで覚えられるけど。
今のARMは、Cortex-A/R/M シリーズに分かれていて、特にAシリーズをCPUおよび
周辺の初期化まで自力で機械語で書くのは、ちょっと無理なんじゃないかな。
通常は、ありものを使う。
>>195 エディタだけどVisual Studio Codeいいよね
VSCodeはいまだにダイレクトタグジャンプの出来ない糞エディタ
swiftって言語として、ライブラリの充実度として有望なの？
>>224 cobolって手間暇掛かるだけで基本cよりはるかに簡単だもの。
ぶっちゃけcobolは他の言語+sqlでいつでも書き換え可能だが
cみたくなんでもできちゃう言語はかなりどうしようもない。
c++みたくフツーのプログラマが全く触らない標準ライブラリから派生したツールなんてもっとどうしようもない。
>>224 COBOLは20年前から終わった言語扱いだから
大学のプログラミングの授業で入門者相手にCを教えるのはやめるべき
>>233 ぶっちゃけ組み込み以外の世界じゃもう殆ど意味の無いアセンブラコンパイルだのポインタだのの要素弾けばcほど分かりやすくて強力な言語未だにないぽいのがなぁ
>>1 cは暴れ馬
手綱をとれる者だけが扱えば良い
無理なら簡単な馬を使えば良い
>>1 大丈夫だよ。ウィルス作っているやつも
C/C++を使っているからミスってうまく動かないはずだ。
同じぐらいの出来のシステムで殴り合いするんだから、
最悪でも分け（50:50)だよ。
まだ、世界は半分残っているじゃないかぁ。
C/C++は他の言語とは違う
>>1 みたいなことを言っているやつは最初から近づかなくていいし、RustがC/C++の代わりになることは永久にない
プログラミングの初学者にCよりもPythonのほうが簡単だと言いがたい。
>>233 同意。Pythonは習得が簡単な言語というのが売りだしね。
学習用に開発されたハードウェア「ラズベリーパイ」もパイソン使う前提で「パイ」の
文字を付けたわけだし。
Pythonはライブラリも充実しているから、専門ジャンルのプログラミングに
すぐに使えるのもイイところ。
要件やプログラマスキルにあった言語を使えよ
Rustの生き残り戦略は悪手だ
アセンブラに近い処理を高速でやる言語 C/C++
新しい言語覚えるのマンドクセコさんだよ
>>240 Cは、覚えるのは簡単だけど初学者にとって真に理解するのが大変だと思う。
ポインタもそうだし、メモリリークなどもそう。
間違えるとすぐに暴走するし、初学者が自力でデバッグするのが難しい。
例えばでいうと
int add_five(int a)
{
int ret = a;
return ret + 5;
}
こんなコードを書くと、自動変数を返しているので動いたり動かなかったりして
すごーく悩む。挙句の果てにコンパイラのバグとか言い出す。
これがダメな理由をまともに説明しだすと、スタックの説明やらヒープの説明やら
変数がどこに確保されるかの話に直結する。
Pythonは、インタープリターもあるので少しづつ動作を確認することができるし
今時の言語なのでＣのようなメモリリークは起きない。
わりとすぐに的確なエラーを返すので学習しやすい。
と、俺は思っている。
現役引退したが、Cは３０年ぐらい前に習得した。
>>96 OSがメイン関数呼んでくれなきゃ動かないCのプログラムだけでOS書くのは無理だろうが
うわぁぁ。自動変数のポインタを返す関数にしようとして
>>252 ご指摘ごもっともデス。(ノ≧∇≦)ノ⌒・。.
>>251 別に普通に動くコードだよなーって思ったｗ
>>255 も、もう許して～。251のライフはゼロよ
つーか
>>1 の主題はC/C++という鋼鉄の巨人に竹槍で挑むRustの話だからな
>>247 Ｃ言語は、アセンブラの知識が無いと、うまく理解できないよ。
>>251 Ｃの最高にいい点でもあり、最悪な点でもあるのが、ポインター。
言わんとしてることはわかる。
文字列扱うだけで、ポインター問題が表面に出るのがＣ
最新のＣＰＵは、計算リソース余りまくりなのだから、配列ごとに、out of rangeかどうかいちいちチェックするメカを入れればいいと思うんだ。
out of order 実行や IPCよりも、重要なことにリソースを。
例えば、文字列でもいいけど、配列を生成する。
配列の下限と上限を取得する。ポインターがこの範囲にあるかを１命令でＣＰＵがチェックする。
範囲外なら、exception出して、拾う。
仮にだけど、b = *a with range low_limit , high_limit、と書ければ、いいね。
でも、今は出来ないから、いちいちチェックするメカを自前で実装しないといけない。
すると、遅くなるから嫌われる。
嫌われるけど、安全な方がいい人もいる
両立は無理なのか？ 多分できるはずだ
ＣＰＵの命令を拡張しよう。
業務ではずーっとJavaを使ってるが、
>>259 >両立は無理なのか？ 多分できるはずだ
CPUでやるよりは言語内でチェックルーチンを
アクセスしている箇所に自動的に挿入だよね。
まぁ、できんことはない。多少遅くなるが。
最近、CもC++も仮想CPU相手にコードはいているから
もう出来るかもよ。LLVMと調べてみたら？
お前らがそんなことやってるうちにCが魔物になっちゃったんだよ
>>259 コンパイラとしてGNUCではなくてLLVM/CLANGを使うと、CLANGの強力な
アドレスサニタライズ機能で、その辺の感じのことをチェックするようにする
強力な機能があるんだけど、アドレスサニタライズ機能ってイマイチ
知られていない気がするんだよなー。実際につかっていろいろ検出できることを
体感すると「すげー」ってなるんだけど。
初心者だったら「ふーん」で終りそうなところがなんとも。
>>250 フリースタンディング環境なら問題ないよ
ブートストラップはサイズ制限やプロセッサの特殊な初期化のために
アセンブリ言語で書くことが多いけど。
>>119 古くい機能は徐々に無くしていってもいいかもね。
関数実行ごとにポインターの確保領域を破棄して、実行段階で再度確保すればいいだけじゃないのかと思ったり
どうでもいいけど、中途半端な言語覚えると、後で衰退した時無駄になるぞ。
毎回領域チェックする仕組みにすれば安全性は高まるけど
>>267 言語の生き残りとしてはそうなんだけど
実際にウィンドウズアプリやＷＥＢ・データベースとかのジャンルで考えると
Ｃは生産性が悪すぎてあまり使わないし。
プログラマーは常に言語を覚えていかなくてはいけないだろうね。
今ウィンドウズのアプリを組むならＣ＃かＶＢだし、会社がＡＩやるって言ったら
Python覚えなきゃならんかもしれない。
１つの言語にこだわりすぎると、その言語と共に運命を共にしたり
ものすごく限られたマイナージャンルの仕事しかなくなったりするよ。
掘らない事でセキュアにはなるかもしれないけど、掘りたい人には糞の役にも立たない
>>64 「安いから」と未だ4bitや8bit数MHzのマイコン使いたがる客がいてな。
全く、ハード屋は部品ケチれば評価されるんだから気楽なもんだよな。
>>274 .NET Micro FrameworkでC#とか？
おまいさん未来に生きてるナー。
>>273 つまりC/C++ユーザ＝ホモ、それ以外＝ノンケってことだな
Rustはホモにもノンケにもウケない糞言語
このスレではあまり知らない人も多いかと思いますが、
>>96 俺は、若い頃にハードウェアの設計から初めてOSからアプリケーションまで全部LISPで作ったマシンを実際に作り上げて
LISPで実質的になんでもできる事を証明した先生に教わったけどなあ
haskelとかでも何でもできるよ
>>279 もとの記事読めよ
どこに問題あるのか、どう言う対処が可能なのか書いてあるから
俺は余りC++知らないのでCの話するけど、Cである程度のプログラム組んだことがあればstrcpy()とかscsnf()の問題とかみんな知っているだろ
だからまずインターフェースを同じにしたままライブラリを書き直して行けって言っているんだよ
>>247 インラインアセンブラ弄くってる時に何となく覚えた感じだな
表面的な知識としては、わかってるつもりだったけど
>>282 引数の受け渡しと自動変数の確保に使われるスタックフレーム
メモリ確保に使われるメモリヒープ領域
初期値ありのDATA領域
初期値なしのBSS領域
あたりを知っているとよいかも。まあＣのプログラムに直接関係しないけど。
組み込みなら上記は必須でさらに
ROMに配置されるデータ、起動時にRAMにコピーされるデータ
を意識ししないと、少ないRAMを食いつぶすし、
パソコンではあまり使わない、volatileで最適化抑止をきちんと行わないと
ペリフェラルレジスタへの書き込みが最適化で消えるし、、、
などなど独特の注意点も多いよね。
LISPなんて意識高い系だろ
>>280 >
>>96 > 俺は、若い頃にハードウェアの設計から初めてOSからアプリケーションまで全部LISPで作ったマシンを実際に作り上げて
> LISPで実質的になんでもできる
すげー
> 事を証明した先生に教わったけどなあ
> haskelとかでも何でもできるよ
がっかり
>>267 そもそもRustはC/C++がごりごりに書けて、C/C++に不満があるプログラマ向けの言語。
C/C++を経ずにRustやっても大変なだけだと思う。
C/C++を叩いているやつ、知ってるか？
>>263 #include<stdio.h>
#include <sanitizer/asan_interface.h>
static char a[200],poison[10],b[200];
int main(void) {
printf("Hello C world\n");
ASAN_POISON_MEMORY_REGION(poison, 10);
int i;
for(i=0;i<200;i++) { a[i]='A'; }
for(i=0;i<200;i++) { b[i]='0'; }
for(i=190;i<220;i++) { printf("%c",a[i]); }
printf("\n");
return 0;
}
こういうのは、全員使うべき。
これ、どうやって実現してるの？
素直に考えると、遅そうなんだけども。
>>275 そのあたりでいくらぐらいなんだろうね。
16bitでも100円で使えるから、それよりグンと安いってこと？
>>291 CLANGの動的解析のASANは、メモリ保護機能を使っていると思ったけど。
だから、使える環境に制限があるのですよ。
CLANGの静的解析機能も強力なのですよ。未初期化変数などはもちろんのこと
メモリリーク（mallocしたけど、それを開放するパスがない）や
戻り値が不定になるパスも検出できるし。
>>292 未だにＰＩＣがあるよ。
ばら売りでも５０円くらいから。
>>274 リアルタイムの世界でC#はありえない
くっそ遅い
AI時代に「何もしない」取り残される日本の危機
業務のデジタル化が進まぬ日本は34カ国中最下位に
http://jbpress.ismedia.jp/articles/-/50416 気の効いたコンパイラか、ソース解析して穴が無いかチェックするツールが開発されてきてないの？
C/C++が死ぬ前に日本が死にそうなんだが
潰れる会社に必ずいる｢静かな殺し屋｣の正体
忖度できる便利な人材は危ない
http://toyokeizai.net/articles/-/179756 Cの一番の問題は、文字列
>>247 &でアドレスを返して、呼び出し元でポインタアクセスしてみると、
スタックにあったローカル変数が消えていてmemory acccess violationになるという話でないんか?
引数も返り値も値渡しで問題が起きない気が…
>>299 あれより実装が簡単な、文字列の表現法を教えて欲しい。
>>300 すぐ間違いに気が付いて
>>251 とかで謝っているのに、、のに、、、のに、、、。
御免よ。指摘はごもっともさ。
>>291 https://solid.kmckk.com/SOLID/archives/703 これを参考にしてみてください。
>>293 なるほど。
#include<stdio.h>
#include <sanitizer/asan_interface.h>
static char a[10],poison[10],b[10];
int main(void) {
printf("Hello C world\n");
ASAN_POISON_MEMORY_REGION(poison, 10);
int i;
for(i=0;i<10;i++) { a[i]='A'; }
for(i=0;i<10;i++) { b[i]='0'; }
printf("%llx\n",(unsigned long long int)a);
printf("%llx %ld\n",(unsigned long long int)poison,(unsigned long )poison - (unsigned long )a);
printf("%llx %ld\n",(unsigned long long int)b,(unsigned long)b-(unsigned long)poison);
for(i=10;i<19;i++) { printf("%c",a[i]); }
printf("\n");
return 0;
}
clang -g -fsanitize=address poison2.c -o poison2.o
Hello C world
138ce80
138ce40 -64
138cec0 128
=================================================================
==869==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000138ce8a at pc 0x0000004ea57f bp 0x7ffc0df83e50 sp 0x7ffc0df83e48
READ of size 1 at 0x00000138ce8a thread T0
0x00000138ce8a is located 54 bytes to the left of global variable 'b' defined in 'poison2.c:4:30' (0x138cec0) of size 10
0x00000138ce8a is located 0 bytes to the right of global variable 'a' defined in 'poison2.c:4:13' (0x138ce80) of size 10
メモリ管理ユニットの粒度がバイト単位も可能なのか、最近のは？？？
配列a と配列b の間に毒沼設定したのに、aの64バイト前に設定されてるように見える。
a と b は１２８バイト離れている。-fno-omit-frame-pointerが強制されるのか。
どこでひっかけてるのかよくわからないが、速度が落ちないんだったら、すごい話。
>>299 ドライバでもなければ
生char使わんだろ。
>>299 ＤＪＢのソースを読むといい。
文字列が使えると言っても、charの配列だから、長さと内容を別に管理すればいい。
そして、ことあるごとに長さチェックをして、容量オーバーしてないかを見張る。
もしバグがあったら賞金出す、としていてバグが無かった。言いがかり的なのはあったけども。
http://cr.yp.to/qmail.html 標準ライブラリでおかしなものは作り直す。面倒だけども、そういう方法もある。
>>297 > 気の効いたコンパイラか、ソース解析して穴が無いかチェックするツールが開発されてきてないの？
根本的な問題として、プログラマーの意図がソースコードにどう反映されているのかわからないんじゃないのかな。
ポインターまわりで。
それの自由度を無くすとガベージコレクションやＶＭやＪＩＴになるのだろう。
ポインタはまじでうざいよな。
>>299 気になるのなら、自前の文字列型を作ればいいだけ
■真相深入り！◆虎ノ門ニュース■
7/18(火) 百田尚樹・居島一平
ダウンロード＆関連動画＞＞ VIDEO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
毎週月～金 朝８時から生放送！ LIVE放送終了後も動画で見れます♪
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
※ニコ生、フレッシュでも放送中
>>305 fopen
ですら生char要求するけど。
Cは息長いからな。
>>290 大抵のLISPはLISPで書いてあるな
pypyというpythonのサブセットで書いたpythonの処理系もある
開発中だがCで書いたpythonより速い場合もあるとか
JAVAも今の処理系は結構実行が速いのでいくつかの言語処理系をJAVAで書いたり
jabaは知らんけどJAVAコンパイラはJAVAで記述されているよ
セキュリティーホールの温床になるからCは駄目という話なのにそこに触れず持ち上げてる奴はバカなの？
>>275 今時の家電製品などで使うような専用ICもピン数を減らすなどの理由で電源を入れるだけでもシーケンス動作が必須だったりするんだよ
電源ONの時にいくつかのICにシリアルのコマンドをいくつか投げるとか、ボタンを押した時にスイッチのON/OFFではなくてエンコードしたシリアルの
コマンドを送るような用途なら小物の部品感覚で使えるPICのような「シーケンサ」が適している
結局問題提起すら読まず理解しない者がCを使うからセキュリティーホールができてしまうのだろうな
>>1 リンク先で言われているバッファオーバフローやポインタの問題は、
最近のC++ならほぼ解決しているけどな。正直生ポインタなんて最近使わないぞ。
DBのOracleがJavaに移行したのは衝撃だったな
>>37 知ったかだなぁ
文化的な背景なんて関係ねーよ
以下３点が理由だ
・（組み込み環境で主流の）linuxやtronのデバイスドライバがCでしか書けないから
・（言語的に単純な）Cが一番早く開発環境揃うから
・Javaとかも動かせなくはないけど（スマホとかのリッチな環境でも無けりゃ）クソ遅い&重いから
リッチコードが使えない組み込み機器なんかじゃC以外考えられないわ
バッファオーバーランなんて言語じゃなくOSの問題だろが
>>83 初心者が使える程度の言語に存在価値あるのか？
>>331 難解な言語じゃないと存在価値ないとか意味不明
>>333 難解さ容易さが問題なのではない。
何ができて何ができないかだ。
初心者向け、あるいはその言語で解決しやすいように整えられた問題に対して、
出題者の意図に沿ったコードを書くのは、初心者向け言語には容易だ。
だけど、世の中にある仕様は、その人の都合を考えてくれるわけではない。
>>294 ということはメーカーが一括購入したらもっと安いのね。
>>330 OSやライブラリの問題
APIがバッファ長を必ず要求するようにしとけば、バッファオーバーフローは起きない
>>338 Javaは配列の代入で必ず長さチェックがかかる仕様なんだよな
最初はバカにされていたけど、今となっては大正解
>>339 それを入れなきゃならんOS仕様の問題だわな。
シンビアンなんて、電力管理をプログラミングに求めてた訳で
>>338 バッファを使うのはAPIだけじゃないんだけど。
>>338 そもそもそのOSやライブラリをを書くために使われる言語についての話題だと理解してる？
>>340 仮想化支援みたいな感じであんまオーバーヘッドがあるようならCPUとかハードでの支援機能があってもいいかもね
（バッファオーバーフロー対策のハード支援はあったと思うから、もしかしたら既にあるかもしれない）
もうC/C++とか超えた世界の話
javaは、androidとWebだけ。
>>292 NXPのLPC800とか、100円台で買える32bitマイコンもあるが、ボタン電池で
動かすとかだと、消費電力が大きくて使えない。
androidもスピードが要求される部分では、
>>339 いくら代入で長さチェックしても、範囲チェックしないで、要素数を超える
配列要素にアクセスするバカはいるので無駄。
速度の為に余計なコートが混じってほしくないってだけのがC言語
死ぬべきなのは、C++言語ではなく、ついてこれないプログラマの方。
>>348 多分それもやってるよ。
JavaだとそこらへんExceptionになったと思うけど、それが長さチェックをやっているってこと
javaはデストラクタがないから、ガベージコレクションが走るように、
安 倍 晋 三 の 実 兄 、 安 倍 寛 信 https://twitter.com/ 東海アマ/status/841451580339625984 https://twitter.com/onodekita/status/881710709624627200 おれ、CASL２しかやったことないんだけど、CとかC++とかやるべきなのかな？
>>1 人間が会話に使う言語と違ってプログラム言語はコンピュータは最近の人工言語なのに、なんでこんなに種類があって複雑なの？
>>357 神様がプログラマーに罰を与えるために言語を分けたって聖書に書いてあるらしい
>>55 サブマイコンとしてならいっぱいあるよ。
それこそソニーやパナでも使っている。
>>357 C/C++が出来れば、大抵のことはできるよ。
>>357 自然言語は勝手に言葉をつくっても
他に話す人がいないと意味ないから
まったく新しいものは生まれないけど
人工言語は人工だからこそ、いろいろ生まれるんだろうな
ここが気に入らない、ここはもっと改善できると思った人が
新しいものを生み出す
javaのruntimeとかVM系は大抵c++
言語なんて何でもいいよ、Application開発に最適であれば。
>>363 でもpythonで10行で済むコードが
1000行になったりするけどな
型と必要リソースが厳密なのは
利点でもあるが面倒臭くもある
boostとか持ち出すともはや別言語だし
>>135 昔、IBMがJavaのWindows用のネイティブコンパイラ出して
Sunに怒られてたような記憶が・・・
Cを代替する言語は現実には無いからね。使わざるを得ない。
>>368 Excelsior JETはAOTコンパイラでネイティブコード吐けるけどOracleにJava互換認定を受けてらしいよ。
今はLLVMでもJava バイトコードをネイティブコードにできたんじゃないかな?
Excelsior JET
https://www.xlsoft.com/jp/products/jet/ > Excelsior JET は、JCK (Java Compatibility Kit test suite) をパスし、
> Oracle からライセンスされています。さまざまなプラットフォーム上において Java 互換認定を受けています。
>>367 それはないな。たとえPythonで書かれたライブラリに相当するC++ライブラリ
がなくても、Pythonで書けるコードはC++でも書ける。どうせ、行末文字の
セミコロンや、{}の省略くらいの節約なんぞ、生産性への影響はないに
等しい。
は、
>>278 ocamlはいいね。
もっとマルチコア対応してくれたらいいのに。
>>15 簡潔にして明瞭、まさに聖典
アレを読んで理解できない奴が他の初心者本読んでも、理解したつもりにされているだけで本質はなにも理解できてない
100年後もCは死んでないと断言できる
>>367 pythonで簡単にできるような機能なんてライブラリ化されているから、自分で書くコードとしては20行もあれば終わる。
C/C++の生産性がスクリプト言語並みだし、WebアプリケーションはみんなC/C++で開発されているんだよ
>>382 このスレに書いてあることは全部素人の書いたデタラメって言っているのと同じようなもんだな(´・ω・｀)
>>348 例外発生してサイレントクラッシュしないだけでも意味がある。
PythonよりもC/C++をやったほうがプログラミングの勉強になるだろ。
>>322 > DBのOracleがJavaに移行したのは衝撃だったな
サンマイクロを買ったら、おまけで付いてきた
オラクルが欲しかったのは、ＤＢ特化型のサーバーかな
何もしていない普通の一般人の自宅に隠しカメラを取り付け
>>390 Javascriptがないという点で統計としては問題のある研究がソースだが、これを見ると言語の傾向が分かる
https://blog.sourced.tech/post/language_migrations/sum_matrix_25lang.svg C++をGithubで最近アップロードした人間は、Pythonを次にアップロードするということ
C++からRustは少数だが、C++からJava、PHP、Rubyを次にアップロードする件数は多い
>>327 Luaはコンパクト
プログラムにLuaを組み込んでも太りません。 配布されているバージョン5.1.4の tarファイル はたった212Kバイトで、
ソースコード、ドキュメントおよびサンプルが入っていて、 展開しても860Kバイトです。ソースコードは約17000行のC言語。
Linuxでは標準のLuaライブラリを含むLuaインタプリタは153Kバイトで、 Lua言語本体の実行時ライブラリが203Kバイトになります。
8bitでは走らないね
Luaはいいと思うよ。普通の使い方なら。
Ｃでないとしょうがないジャンルはあるね。何しろ、使いやすいアセンブラなんだから。
Ｃで言われてる問題は、言語構造の問題でもあるけど、ＣＰＵが根本的にかかえてる問題。
６４ビットのＣＰＵの命令を見直せば、セーフティなＣになるか、より安全で高速な言語が作れる。
セーフティを求めてＶＭ使ってる限りは、Ｃは生き残る
安全装置外した方が速いんだから。
ＣＰＵ自体に安全装置入れろってこと
>>332 Hi-Z状態は重要。XOR回路書いてみ。トランスファゲート使った方で。
>>394 負のスコアへ調整した後の結果
これによるとJavaとC++、PythonでGithubに書き込むのが多いが
golangが意外に強い、むしろ圧倒的に増えてるように見える
pythonの次はgolangを書き込みのも多いように見える
Pythonとか勝手にメモリ管理するほうが怖いと思わないの？
javaからgolangのスコアの高さは異常値だと思うのだが、java開発者とgoの関連性が見えないな
cやc++でもワンライナー行けるよね
C/C++っいうセットにした書き方スゲー違和感ある
コンパイラがほぼ一緒くただからじゃね？
>>337 > ということはメーカーが一括購入したらもっと安いのね。
多分凄く安いんじゃないかな。最近の情勢は知らないけども、３ピンのトランジスタが、１０００個で３０００円。小売店でね。
テーピング納品で１０万個なら、もっと安いだろう。ＰＩＣは８ピンあるんだけも、８円でもおかしくないよ。
プロセス微細化で、もう、ほとんどの領域がI/Oパッドなんじゃないの
あと、ダイシングって言って、シリコンウエファから切り出す時に、無駄な領域が出る。
なのでロジック部を減らす価値がかなり低い。
とすれば、パッケージング代金だけのようなもの。しかし、１円節約できたら、１億台で、１億円の節約。製造業は厳しいね。
GC任せの言語がメモリしか管理してくれないのはどうにもならんのかね？
https://blog.sourced.tech/post/language_migrations/sum_matrix_wdiag_25lang_eig.svg これを見るとFortran、MatlabとRの次にPythonを書き込むのが他を圧倒して多い、Pythonユーザーの多くがプログラマーではなく統計や科学計算をやってるアカデミア出身者ということが分かる
ノンプログラマーのための言語・スクリプトというのが分かりやすい
Rustと最も関係が深いのがHaskell、次にClosureとGo
>>193 今時そんな糞な環境あるかよｗ
とか、思ってたら、この間仕事でスタック128Bytesをやることになった…
RAM自体は4KBと潤沢だったが…
ARM以外のプロセッサ触るのマジで久しぶりだったわ
>>397 これも興味深い。
Rubyの凋落…
PHPはくそ、とえぞえなんとかさんがいつも言ってるが、ポジションがある。Rubyよりもある（笑
Python伸びてない というか昔伸びたんだね
Java人気だね
C/C++ 絶滅危惧種じゃないか
C#に乗っ取られそう
マイナー言語が、長年小さなポジションずっと持ってるのも面白いわ
>>394 は全期間の傾向
ネットで拡散されている図は固有ベクトルの１６年間のプロット
The thickness of each band corresponds to the value in the dominant eigenvector.
問題点はGithubの2000年時と2017年時のユーザーの差だろう
Githubは学生やアマチュア、ノンプログラマーも使うようになった結果としてユーザー数が顕著に増加しているため、
ノンプログラマーが選ぶ言語が最も増える
2008年Githubユーザー数：40000
2012年Githubユーザー数：2760000
これを開発現場で使ってるものと誤認して、その言語を使っても就職・転職活動で痛い目に合うと考えるので注意すべきだ
セキュリティやら質の悪いコーダーやら
>>407 2008年Githubユーザー数：40000
2012年Githubユーザー数：2760000
統計として意味はないので、指標を信じるのは止めた方が良い
Win32ネイティブ開発してたときはC++メインで使ってたけどその頃と比べたら大きく仕様が変わってるらしいね
>>371 こういうのあるんだ。勉強不足だった。
たた、逆コンパイル出来ないのは、ろくに引き継がれもせず、
さらにそれを引き継いで、jadで逆コンパイルしてなんとかなった
経験からすると怖いな。
まぁ、逆コンパイルなんて出来ないのが本来は当たり前なんだろうけど。
>>404 > GC任せの言語がメモリしか管理してくれないのはどうにもならんのかね？
他に何を管理しろと？
ＣでもmallocでＯＳからメモリをもらってくるだろ
これらは、1KBとか4KB単位で管理されてる
それで、ぐちゃぐちゃになったら、OSとＣＰＵが面倒見てるんだよ
粒度の違い ＶＭがやってるかＯＳ＋ＭＭＵがやってるかの違い
まあ単純に率で出してしまうとボリュームの大きなビギナー需要で実用性高いものが薄められて、逆に傾向がつかめなくなるな
>>407 >>410 2008年Githubユーザー数：40000
2012年Githubユーザー数：2760000
で指摘したとおり16年間の推移を示す図に欠陥があるので、
>>394 の全期間の統計図の方が価値がある
アメリカでも使えるJavaが強い点はともかく、就職・転職でこの図を信じたら日本はともかく海外では就職・転職では厳しくなる
誤った情報を使ってアメリカへの移住を減らす行為は悪党の行いであり注意すべきだ
>>413 ハードウェアリソースの所有権とか
DBとのコネクションとか、メモリより厳密に管理すべきリソースはいくらでもあるだろ。
>>72 デルファイいいよな
なんで普及しなかったのか不思議
>>416 もっと具体的に書いて
> ハードウェアリソースの所有権とか
I/Oの排他的処理をＣＰＵがするの？
> DBとのコネクションとか、メモリより厳密に管理すべきリソースはいくらでもあるだろ。
ＴＣＰをＣＰＵが全部受け持つ？
ＯＳで十分なところはＯＳがやればいいんじゃないかな
ＯＳも正常、Ｃ言語も正常なのに、穴があるとかＳＥＧＶで落ちるとかは十分具体的な問題だと思うけども
穴があったりするの？
「初めてのC」タイトル本を見て手に取れなかった時代もあった
それはそうと、機械語で書くくらいならCがいいのだが、C++となると首を傾げてしまう。
これは機械語から見た場合で、ヒューマン操作レベルから見ると
>>1 の通りC/C++は推薦しない。
取り敢えず動けばいいやと試作された他人のＣのメンテを任された日にゃ・・・"(-""-)"
>>420 そうなのか
出てきたときは、VBとc+の中間で絶対はやると思ったのになぁ
おれ、CASL２しかやったことないんだけど、CとかC++とかやるべきなのかな？
ハッカーだから悪党でないという論理等存在しえない
Cはなんでもできるんだから自分でセキュアなライブラリ作ればいいだけだろ
遊びで組み込みやってるから、そんなこと言わないでー
>>417 フリーウェアじゃかなり普及したでしょ。
無くなったのは、開発元がグループウェアに注力するために、
撤退したのが原因。
マジギレしたチームリーダーが、ビル・ゲイツに直接交渉して、
チームまるごと雇ってもらってできたのがC#
>>419 > 「初めてのC」タイトル本を見て手に取れなかった時代もあった
昔、今でもあるか、雑誌 エ／ロ、がアダルトコーナーに置いてあった。よく見たら、 Ｉ／Ｏ だった。
>>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が動いてるよ
パラレルなんとかは、Ｃ／Ｃ＋＋で十分
インテルR Parallel Studio XE がいいかどうかは知らんが、FORTRANとC++は同列のサポートレベル
IBM Parallel Environmentでも、C, C++, Fortran。
>>439 言語がやればいい、のなら、そういうことをする便利なラッパを書けばいいんじゃないかな。
ＯＳは特権モードで動くわけだけども、特殊なことをするのに、ユーザーモードじゃ不十分という意味？
昨日まではCは素晴らしい言語だと思っていた
クソがああああああああああああああああああ
>>443 努力してコーダーになれ
もっともいいのはややこしい言語で書く機会をできるだけ減らすこと
触るのをやめること
これだけで幸せ度ＵＰ
まぁ被害が2000行と少ないのがせめてもの救いやな
>>444 俺は割とバグなくコード書けるで
>>445 時間がないんや・・・
どんな言語使っても、ダメコードを書く奴は普通に出るし
>>447 それがC/C++であると致命傷になるんだよ
他の言語は3輪車に見えるかもしれないけど3輪車使っとけ
C/C++って書き方おかしくね？すげぇ違和感ある
>>449 昔からそういう書き方だから全然違和感ないね
ＣとＣ＋＋に分割しちゃうと
今から20年以上前に俺がN88BASICやってた時はネイティブコード吐きだせるC言語に憧れたもんだけど
>>452 機械語もあったでしょ。
Turbo Pascalと Turbo C はどっちが先だったか。
BASICコンパイラもあったよね。
最近、C++の勉強をやり始めて、ネットで調べながらpaizaのAランクは力技で取れた。
>>454 例えば関数のリターンをenumにして帰ってきた値で何のエラー起こってるか判断する
Assert自作して論理的矛盾みえたらメッセージボックスで関数名通知してそのまま無限Loopに突入させるとか
(´・ω・｀)b
CとC++を同じあつかいしてる
>>456 > それにC++使うぐらいならJava、C#行くだろ普通
用途によるだろ。
お前の想像する「普通」から外れたものには価値がないとでも思ってるのか？
>>458 OSやハードウェアと密接な連携を取る必要がある、もしくは(相対的な)速度やフットプリントの軽さが求められる
Cで構築するには大きすぎる開発案件。
例えば組み込み機器などをターゲットとしたアプリケーション開発や、実行速度が求められるミドルウェアなど。
javaの開発元のワークステーションメーカーのサンがオラクルに吸収されて消滅するとは、あの頃は夢にも思わなかった。
>>460 なるほど
どれも経験ないわ
すまんかった。
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で十分だとなる
ポインターが諸悪の根源なら、ポインターの機能を完全に取り除いた
だから変数の実体をクラスでWrap(隠蔽)してメモリリークしそうなアクセス要求にたいして例外ヴん投げる親切な言語が重宝されてると
>>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のみと思っているかもしれないけど、
使いこなせないロートルと、若年性痴ほう症のゆとりは見苦しいと、
つか、unique_ptrならそもそもオーバヘッド無いから、敢えて使わない事に全く意味はない
C++だとライブラリ作る側でリソースの寿命まで面倒見れるようになるから、そういう意味でも本当に楽
c/c++で書かれたプログラムが資産として、
>>「おぞましい」と言ったのは「悪い」ということではなく「畏敬の念を起こさ
>>486 ひとつのオブジェクトに多スレッドからアクセスって嫌な予感しかしないんだがｗ
スレッド間通信はセーフティなキューとかを用意せにゃあかんやろ
Ｒ言語で書いてある処理をＣに直せと言われたら、発狂しそう
gnu cとclangのマングリングの差異は困るな
>>474 Linusはいろんな意味でアレな人だから
つーか、こんなマイナー言語、1年も経てば誰も覚えとらん。
バイブルである「プログラミング言語C++ 第4版」をトイレに置いて毎日少しずつ読んでる
Ｃ言語と同様に速度も求めたいが
ANdroid NDK叩くだけならRustで十分だろうな
>>503 それ、尿道結石か、膀胱ガンじゃないの？
>>497 メッセージパシング機構ね
そしてこのアクター（スレッド）どうしのメッセージパシングこそが真のオブジェクト指向だと言われている
それを言語として実現してるのはErlang
ちなみにErlangはC言語で作られている
スレッド間の排他処理なら、セマフォか、クリティカルセクションだろ。
>>466 Cを使うと言ってるのに
なんでガベコレがでてくるのか
わからんな
Cでガベコレが出来ないとでも？
そうそう、マルチスレッドの強みはメモリ共有で性能追求できることだもんね
しかし、ゆとりはスレッド切替のコストも知らない・・・
>>507 Erlangのベンチ見たんだが、8コア全て100%使い切れるんだけど、
C++の8倍遅くて実行時間は一緒だったという微妙な結果だった。
そりゃ、Erlangの採用進まないわな
>>511 シングルコアマルチスレッドでスレッド切り替えのコストがか狩るのはわかるんだが、
マルチコアマルチスレッドでのスレッド切り替えのコストってどうなんだろう?
もちろん、スレッドを分別なく作るんじゃなくて、コア数分のスレッドだけ作る
パイプラインみたいな構造にするとして
>>511 そして、老害はメニーコアの時代について行けない・・・
>>386 Pascal式は、文字列の長さが想定を越えると破綻する。
「カーニハンの呪い」
OSやデバイスドライバもかける、速度が速い、
現代の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の回りくどさを
>>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++と同等の実行速度というのは本当なのか
出版社が改訂する人的リソースも割いてない
>>544 応用によってはありうるでしょ
Javaだって応用によってはC/C++より速いし
JITのお陰で
でもRustで書いたライブラリが
OpenSSLの代わりが勤まるかというと違う
>>546 ニセモンだよ
初期のC++にはテンプレートはないから
Hello, World!くらいで実行形式は増大しない
iostreamもまだない
C++、というかC with Classの初期の論文も読んだことない生半可な奴が書いたレベルの低い創作
セキュアな環境はどうやって構築されているのか考えたらナンセンスな主張だとわかろう
>>547 Javaなんかと同じで特定の都合がいい条件を用意した結果だけを出して同等とか言ってるってことか
JITでもまともにコーディングしたC++に最適化かけたものより速くなるわけ無いじゃない。
>>552 ホットスポットはプロファイル取って
統計情報に基づいた最適化
アンローリングなんかも
やるかやらないかどの位するか
実測値に基づいてやる
C言語は、通信、制御系の雄者
Cどころか、Bにも達したことがない俺はどうしたらいいんだ！！！
>>559 そんなことしたら、俺C++になっちまうだろ
手がつけられなくなるぜ
>>560 Cすっ飛ばせば「死を」とか言われなくて済むからいいな
実はJNIにつないでいるオチだろ
>>547 > でもRustで書いたライブラリが
> OpenSSLの代わりが勤まるかというと違う
なんで？
>>572 COBOLはブロックチェーンの進展次第で本当に根絶やしになりそう
まじでメシウマ
巨大銀行はなぜブロックチェーンを研究しているのか？
https://wisdom.nec.com/ja/technology/2017022101/02.html >>566 >処理系はJVM上で動作するため
ないわー
>>566 http://x1.inkenkun.com/archives/179 Python でさえ、NumPy とか使わないといけないのがダルいのに、
Scala って、なんでこんなに解りづらいの？
import javax.imageio.ImageIO;
import java.awt.*;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
頭痛くなった。
これ、javaしか使えない奴向けの救済キットやろ、筋が悪すぎる。
>>575 ,576
F#との比較なら同じようなもんじゃないか?Scala
>>537 「Cの無作法とJavaの回りくどさ」」
これ頂きます
野獣の「C」が作法を持ったら死ぬ
東南アジアのジャングルや～
中央アフリカのサバンナで雄叫びを揚げる「野獣」
それがCです
Cをてなづける、完全コントロールするって行為は
野獣を鉄格子な「ZOO」に放り込むという無謀な行為
野獣性の無い「C」に何の魅力も感じません
>>569 速度が必要とされるアセンブラもどきのコードが沢山含まれてるから
>>578 んーー
Ｆ＃は既に死んでいるのでナシ
RとPythonは使える。
Ｃ/C++も場合によっては使える。低級言語として。
pythonで C/C++コードを自動生成するのが最強
>>580 rustはインラインアセンブリ書けるから大丈夫じゃね？
>>582 つまり、Cython
別に、Ｃでもいいよ
>>583 asm文じゃなくてCで書いてある
アセンブラで書いたソースファイルも含むが
それが存在しないCPUでのビルトは
Cで書かれたアセンブラもどきのコードが使われる
>>570 C++邪悪すぎ
そしてPerlこんなにかっこよくないだろ
よくわからんがプログラム言語自体にセキリティホールがあるとか本当にあるの？
仕様はともかく、標準ライブラリが糞でセキュリティホールが!なんてのは普通
>>586 常に主語が省略される自然言語は日本語ですよ。
>>587 プログラム言語によってセキュリティホールを作ってしまうことを防ぐことはできる(全部を防げるわけではない)。
>>585 1024 2048 4096
----- ----- -----
no-asm 30 148 916
asm 13 46 283
こんなくそじゃまくさいのをようやるな
>>586 リンゴの皮を剥くときに日本刀しかなかったら困るだろ
木を切り倒す時に、十徳ナイフしかなかったら困るだろ
燃料投下
20の言語/環境でてきとうにベンチマークしてみた (Rust, Go, Crystal, Nim, Swiftなど)
http://safx-dev.blogspot.jp/2015/11/20-rust-go-crystal-nim-swift.html > 最速はOCamlとSwift
> Goのシングルバイナリ感がすごい
> Perlは実行速度は遅いが、起動の軽さとメモリ利用量の少なさがよい
> PythonはRubyより遅いのね…
> Rustは1.4.0になって、Cと同等の速度になった (1.3.0はCの4割くらい遅かった)
> CrystalはだいたいC同じくらいの速度。ただしコンパイルは遅い
> Juliaは起動が遅いが、それ以降はコンパイラ言語並みに早い
> PyPyの速度の不安定さ。ちゃんと使うならチューニング必須
> Luaのいろいろな軽さ
>>570 c++とjsは分かる
他は意味分からん
>>597 MySQLのないPHPは実用的に使えない
Ruby / Perl /Pythonは分野が限定されすぎ
C / Pascal / Visual Basicは原始的
Assemblyは今でも使えるが専門的過ぎ（機械言語に近いので）
俺はこういう解釈
これ以外の言語は使ったことないのでノーコメント
>>570 Haskellだけヤク中じゃねーかwww
>>599 当時の西海岸を鑑みるとLと葉っぱとベトナム戦争とヒッピーの相乗効果によってコンピュータ業界そのものが肥大化したと思っていい
なのでその流れを汲むと信じられているハスケルは伝統的な意匠を受け継ぐのでキノコ＝MMの絵となる
LISPの折れたフォークが解らん
アセンブラってオブジェクト出すツールで、コードはアセンブリじゃないの？
>>570 脳内でこんな分類をしてしまうような奴が
言語を扱うこと自体が危険
アセンブラーはアセンブリ言語で書かれたプログラムを機械語に変換する開発ツール
>>607 １６進数な機械語でPG可能です
アセンブラを完璧に熟せるクラスにまでテクアップできると
機械語で直接入力できます
Z80系の石でこれができました
しかし、暴走もそれ以上に得意技になりました
intelだってarmだって出きるだろ
メインフレームは～弾道計算とか爆縮レンズとかの戦争目的からスタート
>>15 誤植（誤訳？）も多いしな
いきなりa.outとか言われても訳が分からなかった
>>606 わからんけど、リミテッド・スリップ・デフじゃね？
PCの最初はマイコン＝電卓ICしょ
アセンブリ言語をアセンブラでアセンブルすると機械語になるわけですよ
>>595 Pascalが五徳ナイフとか全く分かってないよな
delphiじゃないんだから
>>600 Haskellはイギリスの関数型言語文化だよ
オランダやフランスもちょっと混じってる
WikiでAssembly languageをみたけど、単にsource codeだった。ツールはアセンブラ。
>>598 > MySQLのないPHPは実用的に使えない
ふむふむ
> Ruby / Perl /Pythonは分野が限定されすぎ
ほー
> C / Pascal / Visual Basicは原始的
んー
> Assemblyは今でも使えるが専門的過ぎ（機械言語に近いので）
ガクっっ
アセンブラと機械語は同じだよ。
近いとかじゃなく。アセンブラの命令が１対１で機械語に対応してるの。だから逆アセンブルできる。
いちいち１６進数打ち込むのがだるいから、アセンブラ使ってるのよ。
変数名代わりにラベルも使えるしね。
さてはどの言語もろくすっぽ使ったことないな。
Pascal は十分に高級だよ。Ｐコードも含め。
セキュリティについてはCが悪いんじゃなくて、メモリ管理をOSだけでやろうとしてるからやで。
>>602 そのへんは適当だよ。
アセンブラ ： アセンブリ言語を解釈して機械語に変換
ところが、アセンブラ入門とかって本が山ほどあって、アセンブリ言語を、アセンブラ言語とか言ったりしてる。
わかれはいいんじゃないの。
assembly は「組み立て」るって意味。
assembler は組み立て工って意味。
組み立て工が、組み立てを組み立てる、わけがわからないね。
mnemonic てのもある。こっちは、記憶を助ける、って意味だ。
機械語を、覚えやすくしたもの、ってことだね。
>>624 アセンブラと機械語が同じ？
ニワカ過ぎて話にならんな
c/c++って、言語とマクロの２本立てだよな
>>628 cpp は他のものに対しても適用できる。
cppがやってることを理解さえしてれば。
>>624 複数命令にアセンブルするとか
必ず一対一にアセンブルするとは限らんのよ
マクロアセンブラとかもあるしね
>>631 １対１でないものは、○○アセンブラていう派生。マクロアセンブラもそう。
アセンブラ使うなら、機械語にどう変換されるのか確定的なものまで。
なんとなく便利だなでいいなら、Ｃにしとけ。逆アセンブルして、再現されないのはアセンブラとは言えない。それは高級すぎるから。
機械語の１個上の低級なポジションがアセンブラ。
ScalaとKotlinは嫌い
>>632 マイクロコードと命令が一致してないって意味だよ
アセンブラを書ける層って年々減っていって、ロストテクノロジーになったりしないのかい？
システムリプレイス業務で
>>634 マイクロコードは、普通プログラマが扱うものじゃないよね。
>>637 うん。だからプログラマは知らなくて良いのよ
>>636 やっぱりある程度抽象化された言語で書くべきなんだな
>>635 ならないよ。アセンブラが好きな人なんて元から少ないし。
Ｃが出たらＣに乗り換えたのが多いでしょ。
よほど重要な場面でしか、asm は使わないし、既にやってくれる人がいるから大丈夫。
>>638 言ってることが矛盾
マイクロコードであれろうがなんだろうが、機械語の命令は１個。
>>643 ふむ
機械語とマイクロコードの違いは？
>>624 機械語は0/1しかねーよ
お前は0と1だけでコード組めるのか？
>>640 大学の時、プログラム実験を担当した助手のおっさんがアセンブラヲタで、（アセンブラでプログラムを書いてみよう）という課題が出てたのを思い出した
しかも、参考サイトがそのおっさんのfc2ブログ
みんなアセンブラなんて知らないから、約２時間の実験で何度もアクセスするよな
一人が１０回アクセスしたとして、約８０人が受講してるので２時間で８００アクセス( ﾟДﾟ)ｳﾏｰだったらしい
それを言ったら全ての電子情報は0/1しかないと言えなくもない
>>647 大学のアセンブラの授業はCをアセンブラのコードに変換して提出してOKだったな
>>646 8ビットCPUなら機械語レベルで16進数の命令を覚えてるのもいそうだな。
ハンドアセンブルもザラじゃなかったし。
>>636 アセンブラくらいなら新たに書き起こせばいいやん
>>650 2進数で覚える
Z80なんかは頭2桁で演算の種類、3桁x2がレジスタ名とかな
命令の法則から類推される非公式な裏技が使えたり
>>651 しょうがないので
レジスタ名を変数にして
C言語で書き直した遠い思い出
ADD A,B ってどっちだよw
しかし現状のアーキテクチャを使い続ける以上、
>>632 マクロもあるしメモリセクションに関するディレクティブもあってリンカ側で再配置するってな
一つの命令に複数のニーモーニックを割り当てる例もあるのでそちらの方でも必ずしも1対1じゃないな
Cの仕様内で何でも出来るわけじゃない。例えば0アドレスへの読み書きはできないしアトミックな処理も書けない
CPUの命令モードを変える処理とかもそう
そういうところじゃアセンブリ言語を使うしかないよ。変な拡張をして出来るようにしたものもあるけどイレギュラー
OSだったりツールの類、小物の組み込みとかの用途だね
perlもrubyもphytonもjavaも、C/C++で書かれている
>>654 これ、環境によって違うんじゃなかったか？
C言語って昔ながらの標準入出力関数がセキュリティーホールの元凶になってて
>>659 > 例えば0アドレスへの読み書きはできない
OSの制限と、言語仕様の区別が出来ない人？
つ
*(BYTE *)0UL)=(BYTE)0xAA;
で普通にいけるが？
>>512 いずれにせよ、Rust はあり得ない。
>>656 もうあるよ
QMLとか
高階量子プログラミング言語とか
>>660 phytonはそうなのかもしれんが
pythonにはpypyがある
>>512 twitterも事業立ち上げには使ったけど
すぐ辞めただろerlangは
というか今使ってるAndroidタブレットも
C以外の高級言語で書かれたOSという話であれば
>>635 大学や専門学校の電子系の学科ではまだアセンブラの授業があるよ
>>659 ARMだとジャンプ命令やサブルーチンコール命令でジャンプ先がジャンプ可能な範囲に届かないときに
リンカが勝手にベニアコードを追加してくれるな
AArch64、AArch32どちらでもそういう仕様になってるようだ
JavaScriptで38,000ステップ書ききった俺様ならなんでもOK
>>678 無駄な改行を削除して1ステップにしよう
>>665 Cの仕様上ヌルポインタアクセスになる
ならないコンパイラは仕様違反
>>681 べつに、ぬるぽにアクセスしても構わないのでは？
#undef NULL
nullポインターはアドレス0を指している訳では無いから
要はバグを作ってしまう ハッカーに付け入る隙を与えてしまう
>>684 処理系依存だとしても
アドレス0を指してるんならそれでいいわけで。
>>685 現場の頑張りで対処療法的に解消しようとする日本人と
科学の力を使って根本から解決しようとする西洋人の差だと思ったけど。
>>686 ヌルポインタとして特別扱いするように仕様にはあるしそういう前提で多くのプログラムは書かれているんだわ
だから
ポータブルなプログラムは作れない
Cはアセンブラの代わりにはならない
>>644 機械語 普通のプログラマーが認識できる最小単位
マイクロコード 普通のプログラマーは知らなくていい 知っていてもほぼ役に立たない
どうして、こんな話が必要なのかわからない
普通の人はマイクロコードが有ろうが無かろうが、どういう仕組みで動いているかを知ることはできないし、
知っていたとしても、機械語の命令が１ｌクロックで動くのか、あるいは、２や３なのかを知ることに還元される。
>>646 ２進数でプログラムをするような非効率的なことはしないのが普通。
１６進数か８進数でするものだ。
>お前は0と1だけでコード組めるのか？
大昔は、沢山の ON/OFF スイッチがパネルに付いていて、
アドレスを0/1で入れて、データを0/1で入れて、
となっていたが、そんな化石のような時代はあっという間に過ぎて、
１６進数を0-Fまでキー１６個で入れるようになったな。
0と1だけでコード組めるのか、と聞かれたら、ＹＥＳだ。
>>653 だいたい、その通り。
OPコードの解釈も、あなたが知っているような法則で動いている。
記憶によれば、Z80は４ビットを２回計算して、８ビットの結果にしている。
ハーフキャリーフラグは、内部の４ビットの計算結果のキャリーが見えている。
>>654 > ADD A,B ってどっちだよw
原始的なＣＰＵには、アキュムレータというものが明示的にある。これがＡレジスタ。
このＡレジスタに対し何かの操作をするのが基本なので、
A = A+B とわかる。
アキュムレータ以外に対して何かを操作することはできない。
合理的な設計をすれば、何でもできるアキュムレータ１個と、一時的に数値を格納するレジスタが数個という設計になる。
A,B,Cとなっているのは、だいたいそう。A,X,Yも。
レジスタが対象型な場合、Ｄ０からＤ４とか、Ｒ０からＲ７とかになっていることが多いんじゃないかな。
最近のだと、IA32だが、
オペコード 命令 説明
04 ib ADD AL, imm8 imm8 を AL に加算する。
80 /0 ib ADD r/m8, imm8 imm8 を r/m8 に加算する。
81 /0 iw ADD r/m16, imm16 imm16 を r/m16 に加算する。
00 /r ADD r/m8, r8 r8 を r/m8 に加算する。
03 /r ADD r32, r/m32 r/m32 を r32 に加算する。
となっている。このあたりは伝統的なものなんだろう。
IA64でもこのルールをほぼ踏襲。
>>659 アトミックな処理と言うと、セマフォあたりですかね。リード・モディファイ・ライト命令に行きつくわけですが。
Ｃ言語で書ける書けないの話もあるかと思うけども、最低限の実行環境の話もあるでしょうね。
accumulator前提ならADD Bが普通じゃね？
basic、c、fortran、cpp、vb、perl、java、C#など色々な言語を仕事として使ってきたが、一度もc、cppが嫌だと思ったことない。
C縛りのプロジェクトでは
この世はCに始まりCに終わる。
>>694 > accumulator前提ならADD Bが普通じゃね？
そのあたりは方言じゃないですかね。
モトローラは、ニーモニックの所に、レジスタ名入れるのあったかと。
ADDA Aレジスタにメモリの中身を足す
ADDB Bレジスタにメモリの中身を足す
ABA AとBを足してAに入れる
8080方式
ADD B 、あなたが言った形式
Z80方式
ADD A,B
Z80は8080の上位互換だけども、ニーモニックは変えている。
8086方式
ADD AL, -3 等
命令がADD、オペランドにレジスタ名を２つ書く方式。レジスタ以外にも直値やメモリ参照等が書ける。
これが今に至る。
モトローラ６８０００は、命令が
ADD
オペランドが、レジスタまたはメモリ。
source と destination が、他のものと逆になっている。
例えば、MOVE.B D1,D0
の場合、どうなるか。D1の最下位バイトがD0の最下位バイトにコピーされる。
新しい言語についていけない老害がアセンブリ言語について語るスレになっている。。
>>700 じゃあ、どんな言語が新しいんだい？
最近のは一通り使っているが、知らないのもあるかもしれないね。
２－３挙げてくれないか。
>>697 Cに慣れてからCPP使っても何とも思わんが、CPPに慣れすぎてCに戻ると確かにめんどくさい
個人的にはRubyのコンパイラ版のCrystalが健闘しているのが最近知った言語の中では収穫。
>>701 >>1 で上がってるrustとか
新しくはないけどC/C++と同じくシステムプログラミング言語のD言語とか
>>674 Apollo AEGISは結局メジャーバージョンアップする時に
Cで書き換えてDomain/OSと名前を変えた
AEGISの頃からUNIXのライブラリがあったから
古いコンポーネントはPascalで書いたままだったが
書き換えた理由は結局Cが得意な領域だしライブラリも多いから
>>688 アセンブラよりはポータブルだろ
>>665 のコードの方が
>>690 物理スイッチ2進とnumkey16進の間に
numkey8進の時代がある
>>693 行き着いてるのはload link/store conditional命令では？
>>704 Dは事実上終了してます
設計哲学のない言語は使ってもらえない
http://pastport.jp/user/sheltem2/timeline/ 防衛省OBの年表 http://56285.blog.jp Ｒ言語の自由度高すぎで笑っちまう
なんで万能言語を求めるんだ
労害としかいえない、ワンパターンのゲームゆとり脳乙カレー。
>>708 いやいや単純演算のatomicと
atomic_compare_exchangeだろ
GPU系は大抵これ
適材適所じゃない？各分野に文化的なものがあるし、環境的にCしかない分野もある。
>>714 GPUはdata parallelだから
RISCだとll/scの方が親和性高いな
>>712 普通言語は万能だよな
罵倒に特化した朝鮮語とか中華語とかあるけど
なんでプログラム言語は言語によってやることを縛られなきゃならんのが普通になってんだね？
>>718 普通言語の万能さ程度でいいなら、殆どのコンピューター言語は万能だろう。
>>704 Rustはこれから数年すると、環境が変わるかもしれないし、マイナー言語として絶滅するかもしれない。
C/C++を置き換えるには至らないだろう。
Dは、こちらもトラブルを抱えていたが、実用的に使えるレベルにはあると思うよ。
もっと大勢がテコ入れすれば、ひょっとすると、の可能性はあると思う。
現時点で、RustやDを使うメリットがあるかと言えば、わずかなユーザーにはあるんだろうね。
RustはIDEやエコシステムの構築、勉強するのに気が重い、そして出来上がった結果が速いわけでもない。
Mozillaそのものがどこまでやる気あるのか、等の問題を抱えている。
これから当分の間使って安心というエコシステムもない。
Dは使っている企業があるし、その企業が関心のあるうちは持つだろうね。
Dで書いたOSもあるから、OSを書き直す能力はある程度証明されたと言ってもいい。
C/C++ の次はＤと頑張ってる人もいないわけではない。
とは言え、C/C++の膨大な資産を書き換えるコストを考えると、非現実的な部分はあるね。
置き換えるのではなく、守備範囲を広げる、という方法では、Pythonのアプローチはいい方法だと思う。
他の言語を凌駕しているのだから、これを使え、と強制されるのは、反発が大きいからね。
>>707 ８進数マシンは、初期のUNIXにも使われていたね。８進数での書き方は嫌いじゃないよ。
ＭＰＵの台頭によって、１６進数が普及したけど。
>>708 命令の種別はいくつかあれど、
アトミックオペレーションの核となるのは、
読み出し・判断・書き込み、これがリード・モディファイ・ライト命令として、１命令であること。
この命令実行中に、割り込みが入らないこと。
なのでしょう。
これと同等のことを柔軟に実現してるのが、LL/SC、でいいかな？
>>711 どのあたりが、自由度高いと思う？
Rはいい言語だよ。ギスギスしないのがとてもいいと思う。
スクリプト言語もいろいろ。何をしたいかによってもいろいろ。
生産性重視で、実行速度無視、がいいのか、その逆かなど。
ＲはPython とジャンルがかぶるが、いいライブラリが、いい状態でメンテナンスされているね。
ＧＰＵへの対応も早かったし。
やりたいことを書くことに集中できるのがいいと思う。
しかし、ＷＥＢ系には向かないね。Ｒでやろうとすると泥臭いことになって、他の言語に切りかえたくなるね。
>>714 それ、まさに、リード・モディファイ・ライト
>>699 ああ～懐かしいｗ
アセンブラは～電気信号の流れが直接イメージ可能
これってPGにはすごく大切な能力ですぞ
アセンブラ組める人材なら「C」は御茶の子サイサイ
2017年07月24日 12時30分00秒
あなたの使うプログラミング言語は何位？人気ランキング「Top Programming Languages 2017」発表、「急成長中の言語」「就職の際に有利になりそうな言語」も
http://gigazine.net/news/20170724-top-programming-languages-2017/ いま使える言語が将来使える言語なんて誰にも言えません
人工言語は、電脳という人為的に造った架空の言葉
C言語は、ベル研がUNIXという通信系のOS設計のために発明
８０８０とかZ80は、アポロ計画のIC開発陣からスピンアウト組が設計
アポロの司令船に搭載したのは４ビットだったと思う
不易と流行
コンピュータ言語が
>>736 それだけ「電脳」があら世界のプロセスに関与する時代に入ったということです
電脳は、最適化という「オプティマイゼーション」が味噌
業務が細分化されるように人工言語も分派が次から次へと造られていく
佛教が細分化したのと同じです
真言宗と言えば、日本一の霊場「高野山」金剛峰寺が大本山
しかし、この宗派は歴史が古いだけに分派が日本一あります
明治維新以降の新興宗教ですと「大本教」でーす
新興宗教が数多の新興宗教を生み出します
日本宗教界のこのストリームに非常に近いモノを感じます
アセンブラが～アニミズム
宗教界で新興宗教が数多でてくる時代は不幸な時代
大は小を兼ねる
ハッキリ言うが、C言語だけはマトモなPGは皆さん習得済
C使うのはいいんだけどLinuxと同じで選民思想的な人が多すぎなのが嫌
Cは新卒の人が仕事で使って上達していけるほど利用されてないんでは？
だからCがオールマイティなら他人口言語でもOK
リナックスはユニックスを平易にしたもの
>>722 割り込みが入らないのはccNUMAなんかで都合が悪いから
lock freeなアルゴリズムには十分なll/scが考え出された
ところがGPUではwarpベースのデータ並列だから分岐は固定的に最小限にしたい
それで昔に戻した
CPUでもGPUと全く同じでいいかというとそうでもない
>>736 言語の特質
自然言語と人工言語は大差ない
エスペラントですら方言はあるし
手話の動作も世界統一は無理だった
自然言語は、口語から始まる
>>754 単に表現が違うってだけでしょ。
アルファベットまで使う16進数表現が昔はなかったってだけじゃん。
電機と電器・・・この違いがメインフレームとパーソナルコンピュータ
>>756 表現方法、表記方法の有無じゃないよ。
８進数マシンと書いただろう？
つまり、３ビットですね。３ビット区切りがしっくりくるマシンがあったってことさ。
１２ビットくらいが丁度いいという時が。
その後、４ビット区切りがしっくるくるマシンが来て、１６進数の需要が増えた経緯。
なんで頭でっかちなエアプキチガイって連投してしまうん？
>>760 そういう問題じゃなくて
入力機器の問題
8進数使ったのは
まあ昔wordが6bitのマシンはありましたが
>>762 ですよね。
>>760 じゃあ8bit CPUの時代になぜ256進数にならなかったのでしょうかw
>>706 ポータブルではない例を出して「アセンブラよりは」なんて話はナンセンス
処理系依存なコードならアセンブリ言語で意図の明確なコードを書いたほうが保守性も安全性も高い
てか、組み込みの中でも8bitとかリソース制限きつい領域ってだいぶ減ったよな?
>>764 8割の環境で動くコードを書くか、特定の環境でしか動かないコードを書くか。
俺だったら前者を選ぶな。
>>690 オレの知り合いがそうだわ
一旦ビルドしたexeを、バイナリーエディタで修正しよるｗ
原発制御.exeとかなら機械語での精査は当然
ミッションクリティカルの領域だと定理証明系MLの領域だと思うけどなぁ…
>>768 もっと身近なものに、パチンコ用のがあるよ。
最新情報は追いかけてないが、ＣＰＵ指定、アセンブリ言語のソースコード、バイナリも添付、審査だったような。
今でも、
・Ｚ80系アセンブラを使用してのソフトウェア開発
・ソフトウェア関連のドキュメントの作成、検定機関への申請
とかになってるっぽいね。
話が飛ぶが、医療機器のプログラムだけは絶対に嫌だ、という人がいたな。
ミスって人命に関わる事態になるのは、良心が耐えられないらしい。
原発関連の仕事は、まあ、知ってるが、どのように品質を担保してるか。
通常３重のＱＡチェックをするところ、６重にやる。
あまり関わりたくはないね。
納期優先でＱＡがザルなのはどこの業界も同じだからね。
>>763 > じゃあ8bit CPUの時代になぜ256進数にならなかったのでしょうかw
実質的に２５６進数だったね。
１６進数２桁で、０から２５５まで表せるわけだが、例えば、Ｄ０とかＥＦとか見たら、１０進数でいくつになるかすぐわかったものだよ。たいていの人は。
なにしろ、パターンが２５６個しかないし、いちいち道具を使って計算するのは面倒なくらいに、付き合うことになってたからね。
６５５３６までは、割と容易に、という人は多いんじゃないかな。今でも現役でやってる人ならば。
今よりも遥かに、何もかもが遅かったし、リソースもほとんどなかった。
ある程度のサイズになると、アセンブルにかなりの時間がかかったよ。２０分とかね。
となると、少し変更して、アセンブルなんてことには耐えられなくなるんだよ。
ＮＯＰを沢山入れて、パッチ用の領域を置いておく。ある程度の場所にね。
そこに機械語を手入力して、パッチを当てる。
この時、相対ジャンプで飛ばすことが多いんだが、その計算を道具をいちいち使ってやること自体がだるくなる。
なので、どれだけ飛ばせばいいのかは、２５６進数で考えるようになるわけ。
命令セットも、使うクロック数も、何もかもが頭の中に入っていたものだよ。
まともなデバッグ環境と言えるものも無かったからね。
モニター、と言って、１６進数の表示と書き換えができる小さなものだけを置いて、それでデバッグするわけ。
大きなものは入れられない。
初期では、アセンブラとリンカも同時に走らないから、切りかえながら使ってたね。
２５６個のキーがあるキーボードがあればいいとか言いたいんだろう？
キーが多いのは初期のワープロだね。
漢字の数がものすごいから、キーが膨大な数になってたよ。
１６進数の時は、キーは１６個で十分だったし、２桁打てばいいからね。
１６ビット分なら４桁だ。そのあたりに合理性があった。
>>763 何言ってるんだか
wordが6bitの時も7bitの時も8bitの時も
大昔は8進で入力したわけ
A-Fが付いてるキーなんか
コンソールにはなかったから
16進数では入力出来なくて
3bitごとに区切って数値を扱った
内部表現の2進数に近い形で扱う時は
これはアポロのオンボードコンピュータ
>>764 お前の言うポータブルの定義はなんだ？
言語仕様で保証されてない記述があると
もう全くポータブルではないという二極思考か？
現実世界ではポータブルという考えはもっとグラデーションがある
そして
>>665 のコードがターゲット上で意図どおりに動くかなんて簡単にテスト化出来る
だから
>ポータブルなプログラムは作れない
>Cはアセンブラの代わりにはならない
に対してCの方がポータブルだと言ってる
これは妄想でも強弁でもなく
UNIXはそれであちこちで移植されて広まった
アセンブラの利用を最小限にしたOSだったから
>>773 >>763 は
>>760 のヘンな理論wに対してだよ。
>>772 見たら、本人は分かってないようだけど。
c, java, python, perl, ruby, c++, c#, and .net 求人数・求職者数トレンド
https://www.indeed.com/jobtrends?q=c%2C+java%2C+python%2C+perl%2C+ruby%2C+c%2B%2B%2C+c%23%2C+.net& ;l=
job postings＝求人票数＝需要
job seeker interested=興味を持った求職者数＝供給
Java 供給＞需要
需要と供給で見るとJavaは2005年をピークにして供給サイドが過剰
Python 供給＝需要（需要供給は2017年前期では均衡、このままのトレンドだと供給が需要を越す）
Pythonは2016年前期に求人数がピークで、その後は供給が増加するが需要はピークに戻っていない、供給＞需要
C 供給＜需要（常に求職者数が低く均衡した期間なし）
Cは需要の量に比べ供給が低い、需要は2014年前期がピークだが、2017年に大幅に需要が上昇するも供給は安定して低い
ruby 供給＝需要（安定、求職者数も安定）
perl 供給＜需要（求職者がperlを見捨てるが企業側の需要は根強い）
C++ 供給＜需要（需要データが欠損）
C# 供給＝需要（需要と供給が高い精度でマッチ）
海の向こうのプログラマーはC/C++の不満点を改善した新しい言語を作ろうとしているのに
>>770 俺の友人がロマンス系言語のプロ翻訳家
医療・薬学系は値段はいいけど一切受注しません
命に係わる翻訳は誤訳が一切ゆるされません
しかし、誤訳は付いて回る
もちろん機械翻訳なんか出来ません
たらい回しになるみたい、みなさん、この手のクリティカルな御仕事は忌避
これって自由業だから出来る事です
サラリーマンだとしなければならんでしょ・・・良心の呵責と云うか
そのうち麻痺させて受注するんだろうな～罪作りかもしれん
>>778 聴くけど、オマエに新規言語造れるのか？
日本から発信した言語は所詮ローカル言語です
おまえやれよ・・ってバカにしたように云われます
C/C++の不満点て何？
BASICに「Only Seven」技法ってあります
>>775 確信が無ければコメントしなくてもいいのに。
ハードが最初にできます
最初のエニアックって回線を直接つなぐことでPG
タイプもコンソールも無い
電話交換機が自動化される前、交換手という♀が
「どこへ繋ぎますか」
「麻布４６番」
これでプラグをコネクタへ直結
これと全く同じ事を二極管２００００本ぐらいあるところへ繋ぐ
ただね～真空管がこれだけあるとヒータがキレます
室温が上るもんで強烈なクーラーが必要
https://ja.wikipedia.org/wiki/ENIAC >>778 C/C++の不満点を改善する方法は新しい言語を作るだけじゃないよ。
同じ言語でも次の規格を作るのに参加してる人はいる。
今の日本人は、日本語を求めるでしょ。
昔は日本語を扱うこと自体が無理があったのですよ。
なので、英語版のをどこでも使ってたし、それをフィードバックもしてた。
少し前は、日本語が使えない英語のを、どうにか i18nすることだけやってれば良かった。
もちろん、本体に手を入れないとどうしようもないのは、本体にフィードバックしてたよ。
今は、元から何語でも使えるようにしてあるので、日本人が日本語のためにすることはほとんどない。
マイナーな言語を作ってる人はいなくもないし、遅いだの利用者が少ないだの言われても続けている人もいる。
rubyみたいな例は稀有だと思うよ。２０年位以上もやってるでしょ。
>>786 他人の話に、ＹＥＳかＮＯかで乗っかるだけで、マウントした気になってるのがいるなー、って話。
>>789 ＰＧできる人は英語はできます
英語が出来ないＰＧなんて早晩リストラされます
ＡＩが自動プログラム始めます
この界隈がＡＩが一番速く導入されます
電脳は米国で華が開きます
英語なんか論文読めるレベルでやっとこさ
この業界でサバイバル可能
きちんと大学の理学部、工学部の物理とか情報、数学科とか卒業してるだろ？
ＰＧ構築には哲学、法学も役に立つ
こういう基礎の無い人がここにいてもボロボロにされて殺され末世
ゲームソフトの米国製の「シビライゼーション」ですと
日本語版は英語版よりもホンの少しだけ処理に時間が掛かります
言語としてのrubyより、カネの流れのカラクリを知りたい。
>>792 > あいかわらず、よくわかりませんがw
これこそが、他人の話にＮＯだけ言ってマウントしてる例なんだよ。
自分の知ってることを何か書いてごらん。
選挙じゃないんだから、誰かの話にＹＥＳ・ＮＯじゃ全く面白くないわけ。
世界でもコミュ力重要だろ
>>794 >カネの流れのカラクリ
前にphpとZendの話あったろ。
そういう仕組みが無くても、一定の有名人になれば、本も売れるし、
講演するだけでも金が入る。
とても有名な人で１回２００万。
その下でも１００万。
宣伝のために無料で講演するクラスもいる。
何万円も払って、セミナーで偉い人の話を聞きたい人もいるし、
会社が金払って、聞いてこい、と言う場合もある。
４万×５０人で、２００万の売り上げ。そこから会場費や宣伝費用（雑誌社やセミナー会社が多いだろうな）を引いたのが手取り。
これをせっせと、毎月欠かさずやる。
どこにでも出かけて行って、ちょこっと話して、名前と顔を売る。
最早駆け出し芸能人みたいな商売。
rubyの場合、一緒に仕事したいなら、まともな本の一冊も書いた人なら、話聞きますよ、からスタート。
これはかなりの初期ね。
大御所になれば、書かなくても、監修の名前で楽していくらかもらえる。
大抵の場合は、大会社向けに特別パッケージ出したりや、優先的にセキュリティアップデートを供給したりね。
それがうまくいく場合もあれば、そうじゃない場合もある。
詐欺事案とかは個別の話なのでね。被害者でもなければ興味ないでしょ。
全般的に持続可能な儲け方なら、上に書いた通り。
もっとうまくいけば、ＩＰＯとかＭ＆Ａで会社を売る方法だね。
ビジネス板っぽい話になってきたな。
>>797 そうだね。英語で存在をアピールできないのは、いないのと同じだろう。
>>796 なんだかわけわからん面倒くさいこと言ってこらんでくるヤツだな。ここは2ちゃんねるだぞwww
ま、何進数ってのは単なる「表現」の仕方だ。
8進数表記だから3bitが都合がいいとか言うのは本末転倒だわ。
出来の悪い人の将来は、会社には事務手続きに月１回出社
>>734 ソ連の真空管がEMP対策云々は昭和の軍オタの勘違い知識
今そんなこというと笑われるぞ
>>811 当時の話しをしてるの
今は電磁波をブロックできるから「フライ・バイ・ワイヤ」でＯＫ
>>782 生産効率かな。特にCは現代的な機能皆無だから。それを補う便利なライブラリが常に使えるわけでもない。
Cは汎用アセンブラ扱い
>>491 コードは隠蔽性意味なしの割とひどい感じになるよな
全部をリフレクションで処理している様な感じのコードに・・
>>778 日本人はシステム的なものを作るのが超ニガテなんだとおもうわ
仕組みは海外の人に作ってもらってこちらは使う側なだけで良いよ
>>766 コンパイラ依存なんて要素があること自体が問題なんだがな
>>774 処理系依存（あるいは未定義動作）というブラックボックスを抱えることをなんとも思わないなら
これ以上議論しても無駄だと思うよ
>>818 実際そのあたり処理系、実装依存なんだよ
このスレの本来の話題で言うような問題にも処理系、環境依存で予想外の動きをされる場合の話も含まれる
>>819 また「なんとも思わない」と二極思考か
それは詭弁の一つだぞ
>>801 > 日本人のLinuxただ乗りのこと？
日本人で、kernel に初今トリビュートした話って、かなり前だよね。
今だと、かなりの数になってるはず。
他にも、日本語版の話から、keernel以外の各種要素から、いろんな人が絡んでいる。
参加したいなら、誰も止めはしないでしょ。
Lunux だから、全員外人が作ってるとか、日本人はタダ乗りとか、あからさますぎるのはやめてくれ。
わざとなのか、無学なのか。
>>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のボランティアでかなり支えられてます
移植性とか考える必要はあるが、何も努力しなくても、そのままコンパイル実行可能を
>>602 PC初期のころ、タイトルが「機械語～」で
>>812 当時、なんで今頃真空管なんか使ってるんだと悩んだ西側がひねくり出した答えがEMP対策な
で、真相は当時の東側ではまだ真空管のほうが普通に使われて流通してたから
今でも秋葉の部品屋にいくとソ連製の真空管が大量に売られている
>>832 いやアセンブリだろ
普通
アセンブラっていったら通じないことはないまでも誤解を招きかねないし突っ込まれる
>>834 ジャック品ってオモロイ部材に出会えました
真空管回路は単純明快
１つの素子から、どんな回路設計ができるかな「パズル」心が揺れ動く
いま、これが無い
アナログは～鈍重だが非常に分かり易い反応します
Ｃ言語は、英語です
送信機の方簡単に構成可能
自閉症な子って受話能力はピカイチ
バカどもはこの逆をします
いまの日本の風景は、五月蠅い送話しかない
配列のインデックスチェックを無駄に繰り返すことは避けたい
>>844 foreach的なもの使えばいいだけだからCに拘る必要なし
>>536 「はじめてのC
さいごまでC」
シーシーオシッコ
やはり、ヴァイタミン「Ｃ」が足りないようです
>>156 御意・・・
その通り
Ｃ言語って忍者と云うか蛞蝓というか～
明確な形が無い
♀とオマンコしてるんだが
オマンコの情況が良く分からん
普通はオマンコは定期的なサイクルで締まる・緩むですけど
Ｃ言語♀の万個は、挙動不審
ＰＧ屋してるの、この怪しいマンコをどのように調教しようかという
途方もない欲望に捉われます
>>156 「制御構造とメモリ管理」
これに尽きる、頂きました
>>830 Vineってw
いつからLinux使ってないんだ?
>>849 １０年は仕事では弄って無い
ブドウ球菌にヤラレタみたいｗ
この業界から脚を洗いました
いまヘベレケしてますんでマトモな返答は保証できません
今の王様はWeb、スマホのアプリケーションプログラミングだと思うけどなぁ…
ゼニカネを主軸に置くと、Ｃ関係は不要
不易流行
機械語、アセンブラから入ったモンに言わせると「Ｃ言語」は高級言語
>>848 C言語で
制御はわかるが
構造ってなんだい？
メモリが数KBや数十KBの頃はアセンブラ全盛
スマホともなると、一番上のアプリと言われるユーザの目に触れるものから、
>>854 古いよ。
一昨年辺りから機械学習やIoTに移ってる。
>>863 MITは8年前にその辺をカバーする良質のライブラリがないschemeは捨ててpythonを使うことにした
>>862 スマホじゃICEはなかなか使えないだろう
ユーザーの見えるところにJTAG端子が出ていないし
リソースが限られた世界でＰＧできれば～今の無尽にリソースを駆使できる環境は天国
Ｃ言語は樹木の「幹」
>>858 おまえさん
ＰＧ向かん、他業界へ転身しましょう
ＰＧってゼニカネから離れたところで趣味的に弄るのは楽しい
小保方晴子 ＞＞＞ 前田敦子 菜々緒 長澤まさみ さとう珠緒
>>868 もう遅いや
C言語で制御構造って教えて
if とか for() とか break とかそういうの
>>871 >>868 >>826 そういう曖昧で見落としやすくて間違いの元になりやすいこと自体が問題だと言っているのではないのかな
linuxのGPIOのある特殊なプロトコル向けのドライバでBIG endianのCPUを使って2ワード以上のI/Oを行った場合にだけ起きるバグを見つけたことあるけど
こんなの誰も問題が起きるなんて思っていないんだろうなぁってな
そもそも特殊な条件でないとテストもできないし環境を揃えても基本的なテストだけなら通ってしまう話でね
そういうのが言語処理系の曖昧さで発生したらとっても嫌じゃん
>>859 「開発効率と、メモリの無駄遣いをどれだけ許容できるかを天秤にかけてる」
御意
まことにその通りです
シビアでクリティカルな環境下でＰＧ経験をしますと
現今のプログラム開発環境なんて天国クラスです
>>247 Ｃ言語は自由度が高い
自由度が高い＝目的地に必ずしも到達しません
枠にはめられてないもん
野獣だな
これは愛人みたいなもんだな
スクリプト系は本妻です
ベル研の開発した通信系の言語
通信の本旨って「自由」にある
拘束を嫌がるのものです
馬で言えば「ジャジャ馬」
人で言えばどうぢようもない「不良児」
これがＣ言語の特長です
真の市場経済が拘束を嫌がるように「Ｃ」もそういうの大嫌い
お城の構造に例えると～
戦場に「鎧」「兜」なしで素っ裸な「ストリート・キング」するのがＣ言語
日本のマイコンが滅びたのは
>>885 ARMのCコンパイラはまともだったからな
>>886 比較したらどのあたりがどうまともなんでしょうか。
>>864 Pythonは、ただのラッパーですが？
国産Cコンパイラもgccベースのは割と...いや、酷かったな。
なら日本の天才育成システムが上手く行ってないだけじゃね
>>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--なら実際にあって
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となる
あと、C++はねつ造くさいな
普及するようなものではない
Cのmain関数すら呼ばれてないマイコンの起動直後にいろいろ弄ったりするくらいしか使わないなーアセンブラは
>>928 そりゃCがアセンブラをほぼ駆逐したんだから
低レベル記述可能言語として
>>922 ポインタなければそれは不可能だった
>>931 Cは低レベルの記述は欠陥品だけどな
できないことが多すぎて話にならん
それっぽいことのうち一部の事ができることもあるという程度
勘違いする奴多数なので今となっては有害でしかない
visualstudioにパイソンgui入れてくれ
>>932 現実を見ろ
自分がどんだけ馬鹿かよく分かるだろ
>>933 まずironpythonのpython3化を先に…
>>935 現実？
Cで逆立ちしてもできない事とか、出来ても恐ろしく不効率になる所ではアセンブラ使っているよ
バカには見えないかもしれないけどな
>>935 というか
お前「Cでできないこと」が想像つかないんじゃないか？
アトミックな処理とか
CPUのモードを変更する処理とか
スタックフレームを直接操作する処理とか
この手の処理はデバッガでは使うぞ
>>922 Cから、ポインタを除いたら、即、要らない言語になる。
>>938 プロセッサ固有の処理を入れなかったからこそ、普及したんだが。
もしかして、全てのCPUがモードを持ってると思ってる？
> スタックフレームを直接操作する処理とか
あえて操作できないようにすることで開発効率を上げていることに気付こう。
なんでもできることは必ずしもいいことじゃないんだよ
>>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への
OSを全部C以外で作らないと無くならないんじゃね。
本当の戦場はOSとアプリの中間だと思うけどなぁ
ポインタが、バグとセキュリティ・ホールの多くの原因を作っているから、
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 [-]
>>975 Cと比較したらC++の方が見やすいと思うけどなぁ。
hodgesrm 160 days ago [-]
>>975 WebKit等、膨大な資産が現役なんだが?
他にいい言語あるならとっくに駆逐されてるはず
アセンブリの一つ上の水準の言語が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 年 ソフトウエア科学会大会チュートリアル)
産業界の一般的な反応？
.... ＜関心がない＞
今必要なものは新奇な言語ではなく，サービスやビッグデータ基盤
Ｃ言語は汎用言語なゼネラリスト
俺に死ねというか、大塩佳織の件ふくめてなんとかしろとしか言ってない
>>996 Javaは今のCOBOLの地位に収まりそうだな。
20年後、60歳過ぎのジジイがJavaで書いた業務プログラムを細々と保守している姿が目に浮かぶ。
>>990 MLの特徴はREPLじゃなくて
Hindley–Milner型システムに基づいた強い型付けだよな
REPLじゃなくてそっちが
>>985 に貢献してると言うなら分かる
このスレへの固定リンク： http://5chb.net/r/bizplus/1500273631/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚 」 を見た人も見ています：・【IT】Linux on Galaxy/Samsung DeX、Eclipseを使ってC/C++プロジェクトを作成 PS4/Switch『妖怪ウォッチ++』ヨドバシでの売上は34位&1079位！発売初週なのに順位が大爆死 【IT】4月の人気プログラミング言語、「C++」が「Python」を抜いて3位に浮上 【IT】COBOLに罪はない トップ自ら情報戦略を 【IT】COBOLシステムがAWSで動く 維持費「8割減」 【IT】ChromeとSafariで90％超 - 12月モバイルブラウザシェア 【IT】Chromiumベースの次期「Microsoft Edge」、Chrome拡張機能をサポートか 【IT】COBOL廃止とPython追加--IPAが「基本情報技術者試験」を見直し 【Debit Card】CentraTech(CTR)【Insured Wallet】 【IT】CCC、Tカードの購入履歴から商品をクチコミ「カッテミル」が年間ランキングを発表 【IT】CIAがMac・Linux用バックドア・ルートキットを設置する3つのハッキングツール開発が暴露されて発覚 【IT】Cisco大変身、ハードウェア屋からクラウドベースのサブスクリプションモデルへ、今度はSD-WANのViptelaを買収 【超高速】C/C++に代わる低級言語を開発したい 8 【悲報】Switch版のマインクラフト消化率２０％のハイパー爆死 今週発売のSwitchサードタイトルが全滅！消化率1～3割の大爆死 【IT】Mozillaが「WebAssembly Studio」発表。C/Rust/AssemblyScript対応のオンラインIDE 【IT】「Jenkins X」発表。Git/Docker/Kubernetesに特化したことでCI/CD環境の構築運用を自動化 【通信】「下り440Mbpsほぼ全国化」＋「規制ルール変更」のWiMAX 2+に死角なし？ 【害虫】ヒアリ、住宅内で初確認…家電段ボール箱に死骸 【教育】プログラミング教育｢必修化｣に死角はないか 創造性を拡げるのはプログラミングではない 【iOS】iPhoneに死後のアカウント管理人を指定できるデジタル遺産機能。iOS/iPad OS 15.2が配信開始 [田杉山脈★] 【IT】Microsoft、C++技術で.NET Core 2の高速化実現 【IT】PayPay、URLで送金可能に 【IT】CloudFlareがNetwork Time Securityプロトコルのオープンソース実装をリリース 【IT】「ザ・ノース・フェイス」もZOZOへの出品停止 【IT】AI人材求人、2年で3倍 金融・不動産など急増 【IT】ATOK 2019は「まいかた」を「枚方」に変換できる 【IT】楽天、ロゴ変更 「楽天」から「Rakuten」に 7月1日から順次 【IT】CPUアーキテクトのジム・ケラー氏がIntelを辞職 [ムヒタ★] 【IT】年収2000万円は当たり前、知られざるアクセンチュア 【IT】若い世代のテレビ離れ。スマホで視聴が当たり前 【IT】「Slack」日本語版ついに登場 【IT】流通業界の人手不足 ＩｏＴで解決を 【IT】Slackの日本語版が年内登場 【IT】還暦COBOLはお荷物なのか？ 【IT】日本を揺さぶる「ＩＴ韓流」 【IT】COBOLで構築された米失業保険システムで混乱 [田杉山脈★] 【IT】ソフトバンク、韓国のEC大手に2200億円投資 【IT】世界一のAWSユーザー「Netflix」 【IT】ブロックチェーン、資源取引に活用 【IT】トヨタ、米ウーバーに550億円を追加出資 米報道 【IT】Google、仮想通貨広告を日本と米国で一部解禁へ 【IT】Wi-Fiを暗号化するWPA2に脆弱性 【IT】KDDI、楽天と業務提携 通信設備や決済で連携 【IT】インターネット速度は30％以上高速化、日本も向上 【IT】総務省、米Apple聴取 本社幹部「GAFと同列に違和感」 【IT】韓国・台湾パネル大手、一転苦境 【IT】増え続けるＩＴ人材の脱韓国 【IT】楽天、ブランドロゴを変更 【IT】Googleの情報収集は邪悪か？ 【IT】オラクル技術者が足りない 「枯れた技術」維持に危機 【IT】LINE、AI技術を開放 巨額投資でGAFA追う 【IT】メルカリ、フリマ商品を海外から購入可能に 【IT】丸紅、イスラエルのサイバー犯罪対策ソフト 国内で販売へ 【IT】中堅中小SIerの逆襲が始まる 【IT】Appleの修理サービスは赤字 【IT】機械学習の波、メモリーへも 【IT】就活にLINE浸透 企業側も歓迎 【外資】IBM Part1【IT】 【IT】Amazon、自動化の影響を受ける従業員再訓練計画に7億ドル 【IT】ChatGPTは「iPhone」やグーグル検索のような時代を変える技術になるか [田杉山脈★] 【IT】ワーナー動画配信、月15ドルで20年5月開始 ジブリも 【IT】Twitterは生き延びられるのか？ 【IT】フェイスブックの不正利用 日本で最大10万人分流出の恐れ
07:03:40 up 25 days, 17:27, 0 users, load average: 9.26, 9.49, 9.43
in 0.24448800086975 sec
@0.24448800086975@0b7 on 010621
![【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚](https://rz.anime-tube.win/pic.php?http://pbs.twimg.com/media/C_9r-_JUIAA9puw.png)
![【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚](https://blog.sourced.tech/post/language_migrations/erik_red.png)
![【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚](https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png)
![【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚](http://livedoor.blogimg.jp/netagazou_okiba/imgs/0/f/0fb821a1.jpg)
![【IT】C/C++に死を [無断転載禁止]©2ch.net YouTube動画>1本 ->画像>7枚](https://history.nasa.gov/afj/pics/dsky.jpg)
