Linus「C++プログラマはウンコ。寄ってくるな」 2
2 :
デフォルトの名無しさん :2009/02/11(水) 15:46:07
これは支持する。
パート2はマ板に立て直すかと思ってた。
.llllll : ,,,,,,,,,,,,,,,,,,llllll,,,,,,,,,,,,,,,,,, : llllll!!!!!!!!!!!!!!!!!!!!!!lllllll : llllll llllll : l!!!! ,illlll′ ,,.llllll,、 . .llllll,,,, ,,illllll゜ ゙ lllllli、 . llllll! ,,,illlll!゙ , ゙!!!!" ,,llllll゙ ,,,,iilllll!!゙ ウェーハハハ♪ , ,lllll!° -、_ llllllll!!゙゙゜∧_∧ シュー。:*゚ ,,illlll!゙` `‐-、_ < `∀> f 。:*゚。 ・。*:illlll!゙° `-,ノ ,つ[_]; llilllll!!゙゙` (〇 〈-`'" (_,ゝ ) `‐-、_ (__フ `'‐-、,_.. `‐-、
リーナスなんてウンコ臭くて誰も近寄らねぇよってんだよ
2スレ目なんていらねえだろw
>>3 そこまでの知能が
>>1 にあれば
そもそも2スレ目なんか勃てないだろう。
このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
2糞目
∧∧ 〜′ ̄ ̄(,,゚Д゚) UU ̄U U
_ ,、_,、 , ゙フ ゙) 'д')__ノ,ミi 1サーン ハァハァ i彡'^ヽ. i―'゛ 〉 `--、 ,,,,,,,,, / / ̄フ/ ( 'д)_ ウワーン、キモイヨー ,ノ/ レ' ノ 1. r' レ' ゙-'`ー'
平均以下ってところがポイントだな
14 :
デフォルトの名無しさん :2009/02/14(土) 14:14:56
class C++Programmer : CProgrammer { Productivity OOP(); }
こいつマイクロカーネルの悪口も言ってただろ。 単なる老害
マイクロカーネル(笑)
17 :
名無しさん :2009/02/14(土) 18:31:42
立場的にC言語でも困らないレベルの連中とだけしか仕事してないからそうなるんだろうな。 底辺にいくと、自分の技量がある段階を超えたらC++を使った方がやりやすくなるよ。 ザコ用にいろいろ準備したり制限かけたりできるし。
C++でないと出来ない準備とか制限って何? インタフェースと実装を分ける、というような話なら Cでもプロトタイプ宣言で出来るし、コーディングスタイルに 関することならCでもC++でも出来ないだろうし
型の扱いが厳しければCのほうがマシってケースは多々ありそうだけど クラスが無い、型に厳しい、なら関数型言語使うよ 組み込みの人達はそうはいかないんだろうけど
21 :
デフォルトの名無しさん :2009/02/15(日) 00:36:13
組み込みといっても、Objective CとかJava使えるんだから関数型言語もありかもしれん
23 :
デフォルトの名無しさん :2009/02/15(日) 00:40:12
templatemethodとかが適用できるような案件だったら、 「作るべきコード」が強制できる罠。 逆に無理してこうしたパターンに当てはめようとしちゃう所がダメなのかもね。
25 :
24 :2009/02/15(日) 00:46:27
でも「クラスが分からない」レベルで足切りしたいなら有効かもね。 Cだと上下に幅があり過ぎる上に、スキルを測る上での指標が少ない…
クラスのメンバ関数をprivateにできるだけで十分制限になるだろ。
外で自由自在に魔法コードかかれるよ
特定クラスしか受付しない機能をライブラリ化して渡せばそんな程度じゃ困らんぜ。
#define private public
デフォルトでローカル変数がconst扱いになるだけで C++はマシになると思う
変更したかったら mutable か
32 :
デフォルトの名無しさん :2009/02/15(日) 01:27:34
>>30 0xでそれをしないのは本当に馬鹿だと思った。
互換性なくなるだろそんな変更w
ローカル変数なんてほとんど害ないと思うんだが。 そんな長い関数でも書いてるの?
35 :
デフォルトの名無しさん :2009/02/15(日) 01:55:01
良く使うものに限ってconst、constと名前が長くなるのは美しくない
むしろデフォルトでclassをsealedにしろ std::stringを継承するアホがいたので
>>34 "どれも変更されるかもしれません"
"これとこれは変更されるかもしれません"
どっちのがわかりやすい?
>>37 いやローカル変数なんて範囲狭く出来るだろ。
問題としては大きくない。
グローバル変数や大量のメンバ変数もつクラスのほうが問題が大きい。
39 :
デフォルトの名無しさん :2009/02/15(日) 02:23:39
それは定数じゃね。
>>15 いや、AST教授の方が老人なワケだが。
Linusは経験不足な青二才。
>>19 馬鹿避け。大規模案件だと、チーム全員が君のようなスキルが有るとは
限らない。むしろ一番底辺のザコに皆が合わせないといけなくなる。
>>21 使えねーよ。
>>23 さんの言う通り、携帯電話のしかも画面作りだけだろ。
組込みに限らず、デバドラとか書くのにjavaとか使えねー。オシロやICEと
睨めっこしながら、タイミング計算したプログラム書くならアセンブラか、
C(=高級アセンブラ)に限る。
>30-36 そもそもC++のダメな部分て、互換性に起因するモノが多い気もするな。 (特にCとの。)
42 :
デフォルトの名無しさん :2009/02/15(日) 11:36:09
ドライバ作りならPCだってそうだべ。 アプリ作る話だよ。
43 :
デフォルトの名無しさん :2009/02/15(日) 12:51:13
だから、それを「組み込み」と言うのかって話
>>38 範囲の問題にしてるのはお前だけだからww
スレを見る限りC++はウンコ
おまえらがウンコなことはよーくわかった。 スレタイも読めないんだからな。 いいか、ここは「C++がウンコ」のスレじゃないんだよ。 わかったらスレタイの話題に戻せ。
>>46 スレタイの内容について意見の統一ができたってだけだろ
うんこでちゃいますぅぅぅぅ!
自分がうんこプログラマであることは否定しない前提なんだけど C++おもしろいよ。 あと、Cはプログラマはすべてわかっているっていう前提の言語だから レベル低い人が使うとC++よりもひどいことに。
50 :
デフォルトの名無しさん :2009/02/15(日) 13:21:38
>>46 スレタイだけではなく、
>>1 の内容でスレの内容が決まる。
>>1 には「C++ はひどい言語だ。」と書いてある。
つまり、ここは「C++がウンコ」のスレでもある。
C/C++どっちがひどいことになるって言ったらC++のほうがひどい。
俺がC/C++使うとCの方がひどいコードになるなぁ。 C++やると引数が5個以上の関数ってあんま作らなくなった。大体1個か2個。
それって大きなクラス作ってるだけだろ・・・
54 :
デフォルトの名無しさん :2009/02/15(日) 15:35:46
stringとvector使うだけでもバグは減るんじゃねw
>>53 正解!
>>54 アウトオブレンジ系のバグって凶悪なのに簡単にできちゃうから、vector使うだけでも大分違う。
あと、Vector使うとMallocしなくてよくなるからおかしなバグもおきにくい。(もちろん内部ではやってるの知ってるよ?)
そのカッコ痛いからやめた方がいいよ
でかいクラス平気で作ったり、確保領域の範囲外のアクセスを簡単にやっちゃうような ヘボはC++かJAVAかVB(笑)あたりで遊んでてくだちい
クラスはメンバ変数3つ(静的1,動的2)、メンバ関数2つ(なんとかラクタとgetter/setterは仕方ないから除く) までが許容範囲
さすがにそれじゃ今度はクラスが大量に出来るだけ。
Cのがベターって奴はお馬鹿さんへの啓蒙活動に疲れ切って、 とりあえず理想と現実の落差が小さな所に逃げてるだけって希ガス。 まぁLinusみたいに相手を選べない立場に居る香具師だったら それもやむ無しだろうけど。
61 :
デフォルトの名無しさん :2009/02/15(日) 18:02:49
それは当たってる。 人数が多いだけの大型案件だと、情報系でないどころか 未経験の文系出身者が大量に流入して来るからな。 大学でもないのに、ワザワザ給料払ってまで教育してあげる のには疲れ切った。 本来OOPって大規模開発のための技術だったハズ なのに、現実の大規模案件ってオブジェクト指向 どころか構造化すら理解出来ない文系ウンコPGの 巣窟に成ってしまいがち。教育コストを考慮する と、OOPって存在意義が無いわ。
62 :
デフォルトの名無しさん :2009/02/15(日) 18:06:02
C++は、OOPやらなきゃ初心者に優しい言語だよw
OOPが大規模案件向けってのは昔からあるデマだな。
>>59 小さいクラスを大量に作ることは何も悪くないぞ
少なくとも巨大クラスを1個作るよりは圧倒的にまし
「分割して統治せよ」っていうのは スコットメイヤーズ先生もおっしゃっていた。 モノシリックなクラスを少数作るよりも 小さなクラスを大量に作るほうがいい。 さらにメンバ関数は極力減らして、非メンバ関数にするように、とも。
小さなクラスがただ大量にあるのはメンバ変数が大量にあるのとあまり大差ない。
っていうか、モノリシックであった。ひどいtypoをしてしまったと今は反省している。orz
68 :
デフォルトの名無しさん :2009/02/15(日) 19:03:29
前スレのdatくれ
デバッガで追うとすごいことになりそうw
70 :
デフォルトの名無しさん :2009/02/15(日) 19:37:06
>>55 なにこれ?
malloc使ってバグると凶悪で、vector使ってバグるとバグが分からなくなる?
C++プログラマはウンコだからプログラマやめろ。
>>70 凶悪なミスリードだな。
単純に2重開放がなくなったり、OutOfRangeを検出したり利点がある位の意味だけどなぁ。
72 :
デフォルトの名無しさん :2009/02/15(日) 19:46:30
検出できないだろハゲ
物理的には書き換えたかはわからないが、未然に防ぐことは可能だろう。 何のための例外とsizeメソッドなのかねぇ。
74 :
デフォルトの名無しさん :2009/02/15(日) 19:56:57
結局検出できない。 で、1バイト単位での移動チェックね、遅いわけだ。
75 :
デフォルトの名無しさん :2009/02/15(日) 20:00:13
物知りっくwww
76 :
デフォルトの名無しさん :2009/02/15(日) 20:04:43
vectoの.at()を使えば、領域外参照で例外スローする。
>>74 やっぱ遅いって言い出したか。
vectorの場合、オペレータオーバーロードは関数呼び出しのオーバーヘッドが多少あるが、
その中でsize()以上であれば例外を呼ぶし、基本的に場所を補足するのはo(1)だ。
不等式知らないんですか。
あ、MSec以下のチューニングしないといけない人なんですね。
メガセカンド?
想定内だなぁ。ミリセカンドでしょ。
大差ないと同じは違いますよ?
アジャイルプラクティスではバランス感覚が重要だと言っていた。 つまり、(標準ライブラリのstringクラスのような)物知りっくな巨大クラスを設計してはいけないが かといって有象無象のほとんど似たような機能がオーバーラップする小さなクラスをいくつもばら撒くのも間違いだ。
現場を知らずに語っちゃうタイプ多すぎw
85 :
デフォルトの名無しさん :2009/02/15(日) 21:38:15
C++使いの有名人をヲチしてみたいんだけど 誰かいませんかね
>>86 スコット・メイヤーズ
ハーブ・サッター
アンドレイ・アレキサンドレスク
88 :
デフォルトの名無しさん :2009/02/15(日) 22:56:25
>>86 FreeMLでML作ってるエー何とかっていう日本人がいるよ
>>88 エピステーメー?
最近はC#に気持ちが行ってるようだが…
Cryoliteとかcpp_akiraとかはどう?
92 :
デフォルトの名無しさん :2009/02/18(水) 19:47:20
俺は、「プログラマは寄ってくるな」 って言いたいw C++出来ますなんていってる人はイヤだ。 俺様ですらまともに扱えないもんを貴様が使えるわけなかろうて
93 :
デフォルトの名無しさん :2009/02/18(水) 20:09:36
私なら、「少なくともC言語とPerlとCommon Lispを使えないプログラマは、寄ってくるな」 って言いたい。 理由は、 C言語を使えると言うことは、ハードに近い部分も扱えるプログラマであるから。 Perlを使えると言うことは、スクリプトでできることはスクリプトで作ったり、プロトタイプをすぐに提出できたりするプログラマであるから。 まぁ、別にPythonでもRubyでも構わないけど。 Common Lispが使えると言うことは、関数型言語(Lispは、純粋な関数型言語ではないけどね)でもプログラムを考えることができるプログラマであるから。 C++は、中途半端なマルチパラダイム言語なのが好かない。PerlもRubyもだけど。
何故Common Lisp? 関数型というならSchemeか、いっそMLかHaskell。
そしてC++。
97 :
デフォルトの名無しさん :2009/02/18(水) 21:44:45
しかしVerilog。
>>94 俺93じゃないけど、その中からどれか1つということでいいんじゃないかな。
自分はScheme使ったことあるが。
>>98 関数型言語がたくさんある中で、わざわざ
C++と同じ意味で「中途半端」なCommon Lispを選んでるのを見ると、
単に好き嫌いでいってるかんじゃないのかなあ。
寄ってくるな!とまでは思わないけどC派生型の言語しか使ったこと無い 新人には、毛色の変った言語の習得を勧めるな。 思考が限定されてしまうのは、実に勿体無いことだ。
達人プログラマーの続編に当たる(といわれる)アジャイルプラクティスでは プロジェクトには最も適した技術(言語やフレームワークなど)を利用し、 どんな新しい技術にも投資し、古くて生産効率の落ちた技術は捨てろと書かれていた。
俺なら C と Scheme だなー。
C は
>>93 と同じで、低レベルなプログラムが書けるってことで。
Scheme はスクリプト、関数プログラミング、マクロを使ったメタ
プログラミングってとこかな。
104 :
デフォルトの名無しさん :2009/02/18(水) 22:43:25
>>102 そして、投資し終わったころには、投資した技術は古くて生産効率の落ちた技術になっていると。
>>100 自分が使える言語をリストアップして悦に浸るやつは多そうだけどな。
だいたい、言語をあちこち並べる奴の何割が、*きちんと*Cを理解しているやら怪しいもんだ 感覚的に「Cできます」とほざく連中の90%かそれ以上は言うほどわかってない
まぁ「Cを理解してない」と言うヤツの、かなりの割合が 自分がCを理解してないわけだが
・わかってなくても口を挟める ・明らかな嘘を言ってもばれてないような気がする これは論点がどうでもいい所にずれてる兆候。
「Cができます」ってのはどのくらいのレベルがあれば言ってもOK?
面接官の女性がほほを赤らめたら勝ち
>>109 アセンブラと同じことができるようになった場合
ぶっちゃけ Uuix系 OS の kernel を何不自由なく読めるようになった場合
高級アセンブラの異名をとるくらいだから コンパイラが吐き出すニーモニックが透けて見えるレベルなら問題ないんじゃないの? 結局、アセンブラ使って直接石叩いたりすんのがめんどーだから Cとライブラリ使うんだろうし とか適当なことを
113 :
デフォルトの名無しさん :2009/02/18(水) 23:37:21
業務系のプログラマにはハードを直接叩くような要求絶対にないから C言語使えなくてもいいよね!
115 :
デフォルトの名無しさん :2009/02/18(水) 23:40:49
いいよ。
>>114 COBOL, PL/I, PASCAL, Java, C++, … … …
お好きなものをどうぞ
「FORTRAN, LISP には手を出さないのが吉」だと思われる
>116 lispは業務系のPGでも、大量のデータ作ったりするのに使える。 emacs使いには特にお勧め。 そうじゃない人はPerlとかJavaScript、シェルスクリプトでも良いけどね。
Emacsは使ってるけど、そういうときにはRubyちゃん!
>>117 C も読み書きできない奴が Lisp をこなせるとは思えないんだが
>117 Cが分からなくてもExcelのワークシート関数でそこそこ複雑な処理をこなせる奴が居るんだから、 ちょっとしたデータの作成や集計位はできると思うけど。 まぁemacsを使う方が難しいかもしれないが…
121 :
デフォルトの名無しさん :2009/02/19(木) 00:32:40
>>121 それはうそ
native 吐き出すコンパイラ持ってる奴は C よりコンパイラの振る舞い
知っていないとまともな速度が出ません
123 :
デフォルトの名無しさん :2009/02/19(木) 00:47:18
構造体とクラスを明確に分けなかったこととは個人的に問題有りだ。 memcpyとか使って大丈夫なんだっけ? 構造体にデストラクタ仕込むとthisポインタが生成されるんだよね?
>>122 それは簡単かどうかとはあまり関係ないと思う。
>>123 クラスでも構造体でも条件を満たせばmemcpyできるし、仮想関数作ればvtableが作られる。
126 :
デフォルトの名無しさん :2009/02/19(木) 01:00:25
127 :
デフォルトの名無しさん :2009/02/19(木) 01:01:16
C++って経験浅い奴ほど自信満々だよね
例えば?
c++の親玉は音声認識の分野を追い出された人っぽいんだけど 単なる白い巨塔みたいな争いの延長臭い気がしないでもない BSD vs Linux の争いも似たようなもんだったよね. linuxは綺麗じゃないけど,使う側にしてみたらドライバー揃ってるほうがいいから 結局linux使うっていう. 同じ意味での争いがpython vs lispでもみれたことあったな library揃ってるpythonか綺麗にかけるlispかみたいな
C++は何か苦手だ。PERLと似たような苦手意識がある。 何でもできるは何にもできないのと同じ的な印象が強い。 ぶっちゃけプログラム言語は言語自体はシンプルなのが一番だ。 メモリレイアウトに集中するだけで組めるC言語とか、 意味論に集中できるJavaやC#といった言語が素敵に思える。
別に、C++が使いたいから使っているのではなく そのプロジェクトではC++しか選択肢がないから使っているわけで。 結局、複数の言語をいやおうなく習得する羽目になる。
名前空間をサポートしたC言語が夢の言語って意見もあるしね。
135 :
デフォルトの名無しさん :2009/02/19(木) 03:52:59
いいなそれ
Obj-C+名前空間がいいな
(静的な)名前空間 -> 動的な名前空間 -> ADT -> オブジェクト指向 -> そしてC++へ。
ウンコから言わせてもらうとC言語とか云々以前にまずは母国語を(ry
いまどき日本語しゃべれるプログラマの方が少ないだろ! 半数は中国人、1/4は韓国人、残りが国籍不明
140 :
デフォルトの名無しさん :2009/02/19(木) 23:05:44
Effective C++等のルールに沿って禁忌事項を出来ないようにC++の文法を整理すると C#の文法になります。
名前空間だけC++の機能を使えばいいんじゃね。
コンパイルエラーをサポートしたコンパイラがなければ意味がない
図書館でLinuxのカーネル関係の本借りてきて まだ最初のほうしか読んでないんだけど、 読んでてふと思ったことがあった。 もしかしてOSを仮に作るとしたら(実際は作りませんが・・・)、 C言語の標準ライブラリ関数だけでは機能不足だから インラインアセンブラ必須って理解でいいんですか?
お前はカーネルの本なんて読んでも無駄だから本はさっさと返せ
いやです。この本は今日から毎晩ほおずりして愛で倒し俺のにおいをつけまくることにしました。
いや、普通に読めよw
>>143 インラインアセンブラというより生のアセンブラ必須
148 :
デフォルトの名無しさん :2009/02/20(金) 23:21:41
>>143 一応言っておくけど、OSの機能が無ければC言語の標準ライブラリはできないよ。
OSが先で標準ライブラリは後。
で、OSを作るにはインラインアセンブラは必要だろうね。
>>147 「生」が何なのか不明だけど、インラインアセンブラで十分だよ。
>>143 こんなところは, C は書けないんじゃね?
o initial boot 部分(多くの場合 BIOS とも呼ぶ)とか
o 割り込み/トラップエントリーとか
o c の start up とか
>>149 全部Cで書けるよ
というか特に理由が無いかぎりCで書く場合が多い
無理なところは最小限のインラインアセンブラを使うけど
152 :
デフォルトの名無しさん :2009/02/20(金) 23:39:19
>>149 > o initial boot 部分(多くの場合 BIOS とも呼ぶ)とか
BIOSはOSの部分ではない。
> o 割り込み/トラップエントリーとか
インラインアセンブラでかけるだろ。
> o c の start up とか
「c の start up」って何のこと?
どうしてもアセンブラが必要なところは、レジスタを直接書き換えなきゃ いけない所だけ。割禁とかね。 それ以外は全部Cで書ける。効率的かどうかは別にして。
>>152 > o 割り込み/トラップエントリーとか
書けないね
特定のCPUに特化したコンパイラじゃなきゃ
> 「c の start up」って何のこと?
スタックポインタとか最低限のレジスタ設定しなくてcのアプリって実行できるのか?
レジスタを書き換える関数を作って呼べばいい。 それが駄目って言うなら、in/out や int なども C でできないことになる。
156 :
デフォルトの名無しさん :2009/02/20(金) 23:53:48
>>154 > 特定のCPUに特化したコンパイラじゃなきゃ
別に特化しなくてもいいだろ。そのCPUのコードが吐ければ。
> スタックポインタとか最低限のレジスタ設定しなくてcのアプリって実行できるのか?
それをするのはOS。OSのその機能はCで書ける。
ところで、何で「cの」なんだ?何で書いてもアプリはアプリだろ?
さすがにレジスタを直接イジるCの関数は無理だw
世の中には組み込み関数という便利なものがあってだな・・・ __emit__ 最強
160 :
デフォルトの名無しさん :2009/02/21(土) 00:02:09
スタックポインタを設定せずに C の関数が実行できるのか?
c だけで自分が作ったプログラムを boot strtap してみろよ
>>159 いいえ、マシン語を埋め込む[関数]です
OS上のアプリケーションしか組んだことが無い人は、ワンチップマイコンの 評価キットで遊んでみることを勧める 買っても1k円しないし、トラ技のオマケだったりするし どういう風にブートしてるとか良くわかるよ
165 :
デフォルトの名無しさん :2009/02/21(土) 00:24:55
166 :
デフォルトの名無しさん :2009/02/21(土) 00:28:13
UNIXはC言語で組んだらしいけど、どうやったんだろ?
168 :
デフォルトの名無しさん :2009/02/21(土) 00:31:55
>>161 スタックポインタの設定って何だ?
引数の受け渡しのスタックポインタの操作はOSの機能ではなく、普通はアプリが自分でやるぞ?
>>166 boot/*.s の時点で boot してないじゃん
もしかして、OSが無いとコンパイラが動かせないから開発できないとか思ってる知的障害者がいるのかな。
>>168 それをアプリの中に書いてないでしょ
誰かが一度はその部分を書かないといけないわけで
それはCでは書けない
>>170 だから,
c で書かれた code のオブジェクトを startup させるために
最低限必要なレジスター設定をどうやった書くんだ?
って聞いてる
sp をどうやって設定するんだよ? どうやったって, アセンブラが必要だろ?
# それが c の拡張構文の中に収まっていたとしてもだ!!!
173 :
デフォルトの名無しさん :2009/02/21(土) 00:41:53
>>169 あ、ほんとだ。でもまあ、インラインで書けることには変わりないし。
174 :
デフォルトの名無しさん :2009/02/21(土) 00:42:27
175 :
デフォルトの名無しさん :2009/02/21(土) 00:43:16
>>175 だからぁ, 書いてる内容はアセンブリじゃんよ
178 :
デフォルトの名無しさん :2009/02/21(土) 00:45:36
こんな奴らに文句言われるLinusに同情するわ
>>172 Cの関数をアセンブラ・機械語に落とすと、
普通、関数の始まり・終わりにそれぞれスタックポインタ周りの初期化・後始末をするコードがつくけど、
コンパイラによっては、そういうコードを一切吐かないという指定が可能なの。
それ使って、あとは中からインラインアセンブリでスタックポインタの設定をすればいい。
>>180 だからぁ, 書いてる内容はアセンブリじゃんよ
182 :
デフォルトの名無しさん :2009/02/21(土) 00:52:29
>>177 インラインアセンブラに書くのも内容はアセンブリ言語だ。
>>147 の
>インラインアセンブラというより生のアセンブラ必須
と言ったから、インラインアセンブラでもできるって言ってるんだろ。
183 :
デフォルトの名無しさん :2009/02/21(土) 00:53:45
184 :
デフォルトの名無しさん :2009/02/21(土) 00:57:47
>>183 たとえば, lisp の source code 内に、文字列として c のソースを埋め込んで
c コンパイラで文字列をコンパイル/実行したとしするじゃん
こんな感じ
(compile-c-code "
;; 延々 c のコードが続く
")
(exec <上でコンパイルしたコード>)
これって, lisp のコードとはいわんぞ
186 :
デフォルトの名無しさん :2009/02/21(土) 01:02:53
cでさえこうなんだから、c++を排除したのは正解かも
188 :
デフォルトの名無しさん :2009/02/21(土) 01:05:24
>>187 火種になりそうな妙な事はもう言うなwwwwwwwww
189 :
デフォルトの名無しさん :2009/02/21(土) 01:06:02
>>185 それをlispのコードと呼ばないかどうかはわからんが、
インラインアセンブラで書けるかどうかって話だろ?
>>172 はインラインアセンブラで書ける。それだけ。
190 :
デフォルトの名無しさん :2009/02/21(土) 01:09:38
あほな論争にようやく終止符が打たれた
あとは
>>160 が死ねば一件落着
192 :
デフォルトの名無しさん :2009/02/21(土) 01:11:25
>>191 処理系限定じゃないアセンブラってあるの?
>>187 GitがC++じゃないことに対する批判とLinusの反論とは別次元の話だよ。
boot strapをC++で書いたほうがいいと主張する奴は一人もいないだろう。
インラインアセンブラをCと解釈するってアホだろ
195 :
デフォルトの名無しさん :2009/02/21(土) 01:17:24
インラインアセンブラで書けるか、という議論を インラインアセンブラはCか、と言う議論と解釈するってアホだろ
196 :
デフォルトの名無しさん :2009/02/21(土) 01:19:35
197 :
デフォルトの名無しさん :2009/02/21(土) 01:20:51
逆ってどういう意味?
くだらない意地に時間を費やすより、せっかくの機会だから、いろいろ試したり 調べたりしてみては? ワンチップマイコンを弄ってみたり、Cから呼ぶアセンブラの関数をいろいろ 書いてみたりとか。 Cでここまで書けるのかという発見もあると思う。逆に無理なことも。 メインフレームと呼ばれる大型コンピュータのCPUにはスタックが無いもの も多い。じゃぁCのプログラムって、どうやって動かしているんだろうとか。
言語の枠と拡張すら理解できない奴がなにやっても無駄
このスレのプログラマってC/C++で何のプログラム作ってるんだろう?
要点だけ列挙すると inlineのアセンブラは処理系によっては何でも書ける 意地でも関数プロローグと関数プロローグを伯処理系も 存在するようだ inlineのアセンブラにしたってCPU依存だ アセンブリのソース直書きするんと、どこがちゃうのよ そもそも, アセンブリコードが大半のCのファイルが Cのソースと言えるのか? ".c"とか付いてる限りCのコードって言ってええんちゃう ってな話? だとしたら、どれを見てもCの規格の範囲からハズレてるんだから Cですべてが書けるってのは嘘じゃん
203 :
デフォルトの名無しさん :2009/02/21(土) 01:44:40
ふと思ったんだけど、JavaVMみたいに「C実行環境」のようなものが無いと、Cのプログラムは動かせないとか思ってる知的障害者がいるのかな。
>>180 へぇー。なるほど
で、そういう指定はgccでも出来たりする?
ざっと見た感じでは無いみたいだけど、見落とし?
お前の妄想
206 :
デフォルトの名無しさん :2009/02/21(土) 01:47:19
>>202 流れとしては、Cのコードか?とか、Cでかけるか?と言う話ではなくて、
インラインアセンブラで書けるか?と言う話だよ。
>>203 それは誤解だ
JavaVMも仮想とはいえ、ちゃんとCPUでJavaでは書けない部分が存在する
その部分は隠蔽されているが JavaVMのアセンブラで書かれてある
>>204 インラインだったら何でもできるって騒いでる奴じゃないけど
gcc は 3.x の頃から、関数の中身がすべてインラインアセンブラ表現だと
勝手にそうなるよ
# CPUタイプにもよるんだけど…
でも、書いてる内容はアセンブリ以外の何者でもないけどね
まだ、".s"とか".S"をサフィックスにしてアセンブリコードって分かった
方が、コードベースのメンテナンスはやりやすい
>>208 >>209 ありがとう
でも関数からのリターンをどうするんだろうね
インラインアセンブラでjmpしちゃうのかな
それと、結局はインラインアセンブラだけではOSは書けないケースが多いということか
Javaバイトコードには、普通にJavaプログラムをコンパイルするだけなら おそらく使われないであろうものもあると言いたいのだろうが、 それと203との繋がりがよく分からない。
203が知的障害持ってるだけだろ
お題。 ISO/IEC 14882:2003とXLib、Win32APIの範囲内でスクラッチからエディタを作る。 Win32、XLibともに標準C++ライブラリとかぶる機能があるが、この場合 標準C++を優先して使う。 これは、少しでも移植性を高めるための努力と考えてほしい。 また、拡張性の担保ともなりうる。 これは時間かかるけど、やりがいあるよ?
>>215 Win32 は知らんが、Xlib って C バインディングじゃね?
つか、エディタ C とか C++ で作ろうと思わないんじゃね?
普通、拡張用の DSL 設計して最低限の機能をそっちに持たして
残りは DSL で実装しないか?
上にスクリプトエンジンが乗ってると、 下はC++でなくてもCで十分だよな。
また奇天烈な話かよ
220 :
デフォルトの名無しさん :2009/02/21(土) 02:37:50
emacsに持っていくつもりかよ。
xyzzy とか vim とか………
メモリマップドIOならCから読み書きできる。 スタックまわりは無理だが、コンテキストスイッチやらなんやらの関数も当然あるから 記述はできるな。つーかCのソースはアセンブラに変換されるんだから出来て当然というべきか。
224 :
デフォルトの名無しさん :2009/02/21(土) 09:21:39
225 :
デフォルトの名無しさん :2009/02/21(土) 09:24:25
>>224 なんと言うエスパー
その超越した読解力はこのスレにはもったいない。消えろ。
226 :
デフォルトの名無しさん :2009/02/21(土) 09:31:12
>>225 じゃあ、君の解釈はどうなんだ?
>>224 のように補完していいから分かるように説明しろ。
227 :
デフォルトの名無しさん :2009/02/21(土) 09:42:40
228 :
デフォルトの名無しさん :2009/02/21(土) 09:47:29
>>226 お前レベルの補完は書いた人間以外無理だろJK
229 :
デフォルトの名無しさん :2009/02/21(土) 09:52:07
>>228 だから、君はどう補完してどう解釈するのかを示せよ。
230 :
デフォルトの名無しさん :2009/02/21(土) 09:56:02
>>229 >さすがにレジスタを直接イジるCの関数は無理だw (
>>157 )
↓
>インラインで書ける (
>>160 )
これ以降インラインはCと言えるのかというアホ議論に発展
なるほど。 インラインアセンブラの話題で「インラインアセンブラ」を「インライン」と略したら それを「インライン関数」と解釈したアホがいたってことか。
232 :
デフォルトの名無しさん :2009/02/21(土) 10:02:19
233 :
デフォルトの名無しさん :2009/02/21(土) 10:05:27
>>231 次から次へと真打が出てくるなw
その発想はなかった
ってかそんなレスがあったのかどうか
234 :
デフォルトの名無しさん :2009/02/21(土) 10:09:35
結論
>>143 はい。インラインアセンブラ必須です。
「生のアセンブラ」は必要ありません。
235 :
デフォルトの名無しさん :2009/02/21(土) 10:11:20
236 :
デフォルトの名無しさん :2009/02/21(土) 10:12:37
>>235 Cで書けるかどうかではなく、インラインアセンブラが必要かどうかを聞かれているんだけど?
237 :
デフォルトの名無しさん :2009/02/21(土) 10:14:03
敗北した
>>147 がコピペ荒らしを開始したようだな。
239 :
デフォルトの名無しさん :2009/02/21(土) 10:19:33
無限ループって怖いね><
__emit__ 組み込み関数と強制インライン関数を組み合わせたら 関数だけで何でも出来るよ
>>157 がC(の関数で)レジスタがいじれないっていってるのに
Cの文法ではないインラインアセンブラで書けるって突っ込むからおかしいんだろ。
言ってること自体は間違ってないが
>>157 はCで書けないっていってるわけで
Cの文法でないインラインアセンブラでかけると言ってる突込みがおかしいと言われてるのに
自分のいってることは間違いではないの一点張り。
そりゃそうだけどそりゃ会話(レス)じゃない。
インラインアセンブラを使えば、Cの関数でレジスタをいじれるよ。
>>157 の論点は「インラインアセンブラがCの(標準化された)文法か」ではない。
単に「Cの関数でレジスタをいじれるか」だ。
243 :
デフォルトの名無しさん :2009/02/21(土) 11:48:18
>>241 >>143 からの流れでインラインアセンブラの話をしているのに、
「Cの文法でないインラインアセンブラでかけると言ってる突込みがおかしい」と言う方がおかしいだろ。
つまり、
>>147 の言い分だと
WTLを使うと言う事は、アセンブラを使う事だって事か?
そ・ん・な・ば・か・な・!!!
あほばっか
>>243 >>143 は
>C言語の標準ライブラリ関数だけでは機能不足だから
>インラインアセンブラ必須って理解でいいんですか?
とC標準の限界に言及してるんだからおまえがおかしい
249 :
デフォルトの名無しさん :2009/02/21(土) 12:46:13
とりあえず、
>>147 が馬鹿だな
インラインアセンブラは必須だけど、生のアセンブラは要らない
250 :
デフォルトの名無しさん :2009/02/21(土) 13:58:59
アセンブラ => OSを含んだあらゆるソフトウェアが記述可能 C => 拡張機能のインラインアセンブラを使えばOSが記述可能 => C標準関数等だけではOSの記述は不可能。 C++ => C同様に拡張機能を使えばOSが記述可能。標準機能のみでは無理。 => 標準でC互換なのでC言語の機能がすべて使用可(extern "C"もあるよ) 結論: 拡張機能も含めればC++最強!!!!!!!! 拡張機能を含めない場合はアセンブラ最強!!!!!!
asm ブロック自体は C の規格にあるわけだが
C++がウンコっていう命題からずれすぎ
つ [ISO C] [ANSI C]
滅多に使うべきでないパターンを簡単に使えるのが問題。 あるパターンが必要になる確率とそのパターンを使いたいと思う確率が一致しない。
>>251 ありませんが。
あるというなら規格のどの項だよ?
すまん。asm が規格にあるのは C++ だったわ。
asmはCじゃなくてC++の規格 しかもC++でも構文が決まってるだけで中身はimplementation-definedだから asmの中にインラインアセンブラを書けるという保証は標準の範囲内にはない
インラインアセンブラを書けるという保証は無いが、 インラインアセンブラを書けても規格の範囲内だな。
アセンブラの話でC++がウンコな話をそらそうとする輩がうざい。
260 :
デフォルトの名無しさん :2009/02/21(土) 17:26:59
Linusはオブジェクト指向言語をウンコだとは言っていない、C++がウンコだと言っているだけ。 そして実際にC++はウンコ。
C++よりウンコじゃないオブジェクト指向言語ってあるの? 程度と方向性の違いはあってもクソばっかりじゃん
262 :
デフォルトの名無しさん :2009/02/21(土) 17:47:50
C#は神
まあ、ウンコウンコいってるやつにとっては 現実世界もきっとウンコに違いない。 ウンコな世界にいるのは精神衛生上よくない。 あなたの望む世界へ旅立つ事をお勧めします。
きっとハエなんだよ
265 :
デフォルトの名無しさん :2009/02/21(土) 18:51:19
俺もC++使うけど、なんだかんだ言ったってCが一番落ち着くw
デストラクタが無いと落ち着けないわ・・・
267 :
デフォルトの名無しさん :2009/02/21(土) 22:03:34
>>266 たかがそんなことで落ち着けないなんて・・・
素人そのものだねw
268 :
デフォルトの名無しさん :2009/02/21(土) 22:57:41
Objective-Cは間違った進化をしてるとしか思えない
269 :
デフォルトの名無しさん :2009/02/21(土) 23:01:53
例えば?
Objective-Cはちょっと構文見ただけで吐き気がしてくる。 気持ちが悪い。 これはCを語っちゃいけない言語だと思う。
C#とObjective-Cだとどっちだよ。
c#の圧勝
273 :
デフォルトの名無しさん :2009/02/21(土) 23:13:12
>>271 較べるなんておこがましい。
C#は大成功
Objective-Cは大失敗
>>273 単にWindowsとMacの差だと思う
iPhoneやその周辺次第によっちゃObjective-Cもこの先あなどれない
276 :
デフォルトの名無しさん :2009/02/21(土) 23:21:34
構造化プログラミングのC言語をマクロ構文みたいなキーワードを追加して 無理矢理オプジェクト指向プログラミングを実現している
漏れもObjective-Cはいただけない。 構文が泥縄的、あるいは取って付けたと形容するに相応しい。 Cとの互換性はヘッダを取り込み、objを吐ければ十分なんだから Cの構文をそのまま内包する必要は無い。
278 :
デフォルトの名無しさん :2009/02/21(土) 23:22:27
>>275 プラットフォームは関係ない。
ライブラリでも実行バイナリでも比較していない。
純粋に言語仕様の差だ。
279 :
デフォルトの名無しさん :2009/02/21(土) 23:24:42
C/C++ カレーはご飯とルーに分けて食べるタイプ Objective-C カレーはご飯とルーをぐちゃぐちゃに混ぜてから食べるタイプ
C++もObjective-CもC#も 方向性が違うだけでウンコ度は一緒
>>279 違うだろ
カレー(C)に福神漬け(オブジェクト指向)を乗せたのがObjective-C
カレーの具に福神漬けを入れて煮込んじゃったのがC++
カレー→シーフードカレー的進化がC++、 カレー→エビフライカレー的進化がObjective-C。 後者は、乗っかってるエビフライのビジュアルに問題がある。
283 :
デフォルトの名無しさん :2009/02/21(土) 23:55:43
284 :
デフォルトの名無しさん :2009/02/22(日) 00:00:26
2CH憲章 ・奇天烈な書き込みで合意を得られると喜ばしい。
イメージとしてはこうかな Objective-C カレーソースとライスが分かれてる(上品な感じ) C++ カレーうどん(大衆的な感じ)
Objective-C: ご飯の上にカレーうどん用のカレーぶっかけちゃった感じ C++ ご飯に普通のカレー入れたけど、ぐちゃぐちゃにかき混ぜちゃった
大阪にはご飯の入ったカレーうどんがあるんだぞ
>>283 スタンドアロンならjavaのがライブラリがそろっていて楽だし、
ライブラリつくるならどうせCリンケージで出さないといけないのでCのがよい
って感じでしょ。
C++ ご飯とカレーの材料を置いてるだけの感じ(お前ら好きにしろ) Objective-C: 必死になってるだけ
C ご飯とカレー C++ ご飯とカレーにいろんなスパイス並べて好き勝手スパイス入れてから客に出す
Cは米や肉などの材料で薪集めてカマド作るところから始めていく C++は上記に微妙に便利なアウトドアグッズが揃っている
柄に刃が付いたナイフや底に穴の開いた鍋が揃ってるんですね、わかります
柄と刃の区別もつかないバカは料理しちゃいけませんでちゅよー。
実際そういうレベルの人がアウトドアしてるんだよね。 そいつらにバカはアウトドアすんなというと仕事が回らなくなる矛盾。
ソフトウェア開発に限っていえば日本はバカが得をする国だからね。 C++なんか流行らん訳だ。
まるで日本以外ではC++が流行っているかのような口ぶりだな
Cで8年くらい仕事して、C++にして6年仕事してるけど C++のメリットよりもデメリットが大きい印象変わんないな。
柄の所になぜか刃が付いてて握ると手をケガするようなライブラリが C++にはいっぱいあるという皮肉も通じないのか
ライブラリ?
「柄」の所になぜか刃が付いてて「刃」の所になぜか刃がついてないんだろ? 「柄」と「刃」を取り違えてるんだよバーカ、という皮肉も通じないのか
ライブラリ?
標準ライブラリだよ たとえばauto_ptrなんて全方向に刃が付いてるじゃないか どこ持ってもケガする最低のライブラリ
いやライブラリ以前にもたくさん問題がw
302が鬼の首をとったが如くlist<auto_ptr>の話をしだすのに 100 iostream。
日本ではというか、C++は窓以外閑古鳥だろ。 unixに至っては数ある有象無象言語のひとつ。
そう思っていても使わざるを得ない状況がある以上、習得するしかなかべ。 プログラマは言語選ぶ権利ないし。
まあ下っ端とか、請負プログラマはそうだろうね
つまりうわっぱプログラマはC++も使えないカスばかり、と。
C++使いこなしているからこそC++はイイとかダメとかいえるに決まってるじゃないか。 みんなプログラミング言語C++を3回は通して読んだレベルだよ。
>>309 ほとんどネットでその半分が2chだなぁ。
auto_ptrって使ったことないな。そもそもnewしないからなぁ。
総括のクラスをスタックに確保してアプリ完成!って感じだな。
実用アプリってほとんど作ったことないけどね。
大きなアプリ書こうとするとnewは必要だよ。 モジュール・タスク分割してそれらの間のAPIを書くのに newを使うか否かでシンプルにも複雑にもなる。 newをつかって例外安全に書くんならauto_ptr必須。
コンテナに入れられない時点でauto_ptrは使い物にならない。
auto_ptrなんて使えないものを作った奴と標準に含めた奴は切腹しろ
>>312 想定する用途が違うだけなのに、自分が使いたいときに使えないというだけで
ダメ扱いするのは頭悪いんじゃない?
次の標準ではお前の欲しかった shared_ptr も入るよ。
std::vector obj(sizeof(hoge) * n); hoge *pobj = &obj[0]; で十分
316 :
デフォルトの名無しさん :2009/02/23(月) 09:41:13
>>315 中身を解放しませんよ。
ま、ヒープの問題はCでもsetjump longjumpを知らないところで使われたら一緒だし目くじらたてるほどのものかと思う。
>>315 釣られてみるが、
std::vector<hoge> obj(N);
でやらないメリットってなんだい??
>>317 コピーコンストラクタ(爆)を律儀にN回呼んで
貴重な実行時間を食いつぶすから
>>317 クラスの不変条件を達成するにはクラスのメンバ変数を初期化しないといけない。
そのためにはコンストラクタは呼ばれるべきでしょ。
俺の場合だけど、コンストラクタは適当に書いて、Init()ってメンバ関数で本格的に初期化してる。
再利用できるようにも一応考えてつくってる。
あ、また、ミリセカンドでチューニングしてる人か。
>>320 C++を覚えたばっかりで、良く分からないんだが
>>315 だとコピーコンストラクタは呼ばれない(というか、たぶん、コンパイルできない)
std::vector<hoge> obj(N, hoge(1, 2));
と書くと、各要素がhoge(1, 2)でコピー初期化される。
>>317 は、それがデフォルト引数で省略されているだけ。
>>315 はおそらくstd::vector<char>だろうが、
charの初期化なら実行時間が少しはましだったのだろう。
コンパイラが賢ければ、315のようにcharに置き換えて良い型
(コンストラクタがない)なら、
hogeのままでもそう時間は変わらないことが期待できるけど。
一応、次の規格では改善されて、デフォルト引数使う横着はなくなるので、この心配はなくなるはず。
324 :
320 :2009/02/23(月) 22:06:29
325 :
デフォルトの名無しさん :2009/02/23(月) 22:26:45
アホの妄言には付き合ってられんわ
結局、C++一通りやったプログラマってHSPに原点回帰するんだよな。 俺の知り合いも、ついこの間C++の仕事辞めて今はHSPでフリーウェア作ってる。
328 :
デフォルトの名無しさん :2009/02/24(火) 00:31:15
それはない。そもそも原点じゃないし。
>>327 ないしその「知り合い」とやらが初めに触った環境なんだろ。察してやろうぜ
>>323 >デフォルト引数使う横着はなくなる
どういうこと?
vectorはresizeできるのに、 vector<hoge> obj(N);とサイズ決め打ちで確保してるのは横着じゃないの?
>>331 大きさが既に分かっているなら
vector<hoge> obj(N);
の方がいいんじゃないの?
>>332 コンストラクタに時間を取られるので、なるべく呼びたくない、
という話だから。
>>318
>>333 resizeしても、コンストラクターは呼び出されるだろ?
>>334 最後まで参照されない要素はコンストラクトしないで済む。
>>331 細かい話だが、サイズが最初からわかってるなら、決め打ちしたほうがメモリ確保回数が減るので多少マシだと思う。
>>336 大きさの上限が分かってるケースと、
全ての要素が参照されるケースを区別できるようにした方が良いよ。
reserveも使えるようになってね。
あれは構造体のmallocの代わりじゃないの?
>>330 >>331 323じゃないけど
現状の規格で
explicit vector(size_type n)のシグネチャで呼ばれるコンストラクタが
explicit vector(size_type n, const T& value = T(),
const Allocator& = Allocator());
のようなデフォルト引数による実装になっているのが
横着といいたいんじゃないの?
Tのデフォルトコンストラクタがinlineで何もしない実装の場合
新しい規格なら要素ごとにT()が呼ばれるから実質コンストラクタ
呼び出しのオーバーヘッドがなくせる。
すぐこういう話になるからC++はダメなんだよ コンストラクタだのデストラクタだの知らない所で勝手にコソコソ余計なことやる奴が多すぎて Cならそんなこと考える必要もないのに
341 :
デフォルトの名無しさん :2009/02/25(水) 01:37:01
STLの実装に噛みつくなんてどんだけ世間知らずなド素人なんだよww
342 :
デフォルトの名無しさん :2009/02/25(水) 01:43:55
Cはsize_tを画面に出すだけでも破綻するけどね。
DWORD
>>340 今時、どっちもどっちだと思うぞ
算数の計算のしかたもしらん多すぎ!
数値計算やらせると、誤差とか桁落ちとか理解してねぇもん
つか、仕様として数式与えられた時点で、ほぼ全員アウトだろ?
floatの仕組みを理解してる奴が少ない現実。
float関係ないんじゃね? 正数演算であっても x/y * z があえられたときに正直に (x / y) * z って計算する奴多くね?
じゃあ、それってx*z/yが正しいの?桁堕ちの誤差で?
348 :
デフォルトの名無しさん :2009/02/25(水) 10:42:24
floatの仕組みなんて文理関係なく大学の教養で必修としてやるだろ。 少なくとも東大ではそうだ。
いまどきは知らんが、20年ほど前は教養でそんなことやらんぞ。 専門の講義で数値解析やるときくらいかね(高校の授業にコンピュータとかない時代だから、まあ当然か)。 それ以前に、その時代にパソコン触ってた連中はBASICの入門書とかで0.1を10回足して1にならにでしょ、みたいなの見てるから、むしろそっちで知ってるはず。 MSXはBCDだからちゃんと1になるよ〜とかね。
>>349 何処の田舎の話だよ
工業高校の電気科だが、20年前、普通に浮動小数点がどうのBCDがどうのやったぞ
まあ、当時の俺様にはさっぱり理解できなかったがな
double d1 = 1.0 - 0.9; double d2 = 1.0/10.0; assert( d1 == d2 ); うぼぁ。
>>339 でもとにかくオブジェクトの構築は絶対に
必要なんだから、いずれコンストラクタは
呼び出されるでしょ?
コンテナのコンストラクタでわざわざ格納
オブジェクトのコピーコンストラクタが
呼び出されていたのがなくなるということ?
ちょっとした改善?
>>350 いやオレもやらんかったな。
普通大学の一般教養にはないだろ。
有効桁なら高校以下の理科で習ったが。
>工業高校の電気科
だからやったんじゃね。ちょっと特別。
田舎でおk
>>352 デフォルトコンストラクタ(場合によっては+代入)と、コピーコンストラクタでは、
パフォーマンスが違うことがあり得る、という話。
高校レベルの話を大学でやらないとは...
>>357 高校でやってれば大学でやる必要ないのだが?
で、たとえば
>>351 みたいな assertion failed を起こさないようにするには
C/C++/java などではどんなライボラリを使えばいいのか答えなさい(涼宮ハルヒ風に^^)
360 :
352 :2009/02/25(水) 18:35:17
>>356 それはわかる。
格納オブジェクトのコンストラクタがコピー
コンストラクタよりも軽い場合に、コンテナの
コンストラクトが速くなる、ということでおK?
>>360 おけ。
改めて調べてみたら、C++0xだと、コピーできないオブジェクト
(コピーコンストラクタも代入も無し)が一般的になりそうな感じが。
C言語との乖離が広がって、Linusさんがまたぼろくそにけなしそう。
現時点でもfstreamとかauto_ptrとか、 あるいは自作クラスでもコピー禁止にするものが多いよ。 JavaなんかでなんでもかんでもCloneable実装しないのと根は同じ。 コピーして自由に持ちまわれるようにするには、 ポインタ(生でもshared_ptrでも)にしまうのは今でも0xになっても同じ。 いやまあ、コピー不可でもvectorに直接入れられるとか、変化はあるけど。
まあそうっちゃそうなんだけど。 =deleteで{デフォルト|コピー}コンストラクタがないことを明示できたり。 emplaceでpush_backと同時にコンストラクトできたり。 move semanticsが導入されたり。 で、今まで、コーディング上のテクニックですよ、みたいな感じで 使っていたコピー禁止オブジェクトが、言語で手厚くサポートされた 第1級のオブジェクトになったような風向き。
笑えるスレだなw
>>347 が
> じゃあ、それってx*z/yが正しいの?桁堕ちの誤差で?
って聞いてるのに誰反応してないってどおよ???
Linus が, 泣きたくなるのは当然だ
>>347 x <= 1/3; 1/3 == 0; x * 7 == 0
x <= 1*7; (x == 7); 7/3 は少なくとも0じゃない
コピーコンストラクタと代入演算子を意味もなく特別扱いしてきたツケを払ってるだけだろ コピーなんてのは必要な時にだけ用意する操作でいいのに
>>365 structとclassの違いがデフォでpublicかprivateかの違いしか持たせなかったのが根本原因だね。
typedef double Real; とかやる奴とは一緒に仕事したくない。Realはないだろ。。。
real型を組み込みで持つDという言語があってな…
いや、Real型と言えば、Pascalのほうが先だろう。
>>362 >コピー不可でもvectorに直接入れられる
再配置はどうなるの?
371 :
360 :2009/02/26(木) 09:23:36
>>361 はあく。あり。
じゃあメリットは現実にはあんまりなさげ。
>>365 C++がここまでの領域に達するとは、
当時に予測することは不可能。
最初はCの薄喇叭だったんだし、
PODとの互換を重視したのはやむなし。
>>366 そのへん、後発のC#はさすが。
>>365 ,366
C言語のコピー渡し大好き仕様にあわせたのが原因。
>>364 よく
>>347 みたいな曖昧な質問に答えられるな。
>>347 が
桁落ちの誤差の範囲内で正しいのか?と聞きたかったのか、
桁落ちの誤差があるのに正しいつもりか?といってるのか。
未だにわからん。
それに、xの値が大きいときの話が抜けてるよ。
そもそもの前提の仕様としてx/y * zが渡されるってとこでもうダメだろ。 必要な精度も何も書いてないんだから
型も書かれてないしな
377 :
デフォルトの名無しさん :2009/02/26(木) 14:37:30
素人は 他人のアラだけ よく見える
>>370 そのタネがムーブセマンティクス。
新たにvectorに入れられるようになるのは、
auto_ptrのようなコピーがダメでも移すだけならいいでしょうという型。
(auto_ptr自体は非推奨で放置プレイだからvectorに入れられないままみたいだけど)
うーん。 Cと同様にメモリ管理はプログラマサイドに丸投げなくせに、ムーブやらなにやら中途半端に導入されてもなぁ。 そこまでやるならガベコレまで面倒見ろという感じ。
>>379 丸投げじゃない。
deleteを書かなくていいように進化してる。
>>379 ガベコレさえ取り込もうとしているからおそろしい。
いろんな意味で。
>>380 書かなくても、意識しないといけない時点でプログラマに責任を負わせてるでしょ。
ムーブはむしろコードの手間は増えても効率上げたいっていう機能だろ GCとは思想が逆
>>382 意識したくてもできない言語よりずっと頼りになる。
気が向いたら中を見たいけど、普段は見たくないって香具師に向いてる気がする。>C++
>>378 >そのタネがムーブセマンティクス。
なるほど。豚。
ムーブってなんだろ、と見るたびに疑問
だったんだけど、そうゆうことなのね。
使いどころが難しそう。
実際、2ch(匿名)で件の文章だけ見たら、「馬鹿なこと言ってら、こいつ」って思う内容でしょ? 本人に高いスキルがあっていろんな功績、貢献がある人物でも、個々の言動の評価はまた別。 ちなみに無知であること自体を非難するつもりは毛頭無いです。さすがに私もそこまで愚かじゃありません。 たぶん、malloc/reallocだけでの動的メモリ管理云々の文章を読んだことがあるということはその人のブログなりなんなりを見たことがあるんだと思うけど。
>>388 がんばって{c|m|re}alloc/free書いてね。setjump/longjumpにも気をつけてね。
Cなら、malloc/freeが内部で呼んでるbrk/mmapでメモリ管理ライブラリ書いたほうが楽。 完璧に一元管理できるし。
>>392 移植も再利用も考えないなら、なんぼでも手抜きできるやん。
わざわざヒープ解放しなくても、プログラムが終了したら勝手に解放されるし!みたいな。
移植なら、マクロでmallocに置き換えるだけ。 それより、ライブラリのなか全部知りたいだけ。
>>394 で、そのマクロとやらで問題が起きたら「知るかそんなの」でしょ。
その調子でvtblやら例外(のまねごと)やら、全部自前で実装するべし。応援するよ。
それはありがとう。 OSやTCP/IPスタック書くのも勉強になるし。
10年後 396「Linuxプログラマはウンコ。寄ってくるな」
share_ptrやauto_ptrでも問題でたら(使い方間違ってたとかで) 「知るかそんなの」でしょ 同じだよ所詮
>>398 (問題点も含めて)ちゃんとドキュメントされてる。
テストされてる。パフォーマンス、データ型に対する汎用性、移植性も考慮されてる。
知るかそんなの
401 :
デフォルトの名無しさん :2009/02/27(金) 13:31:11
401
402 :
デフォルトの名無しさん :2009/02/27(金) 13:35:49
C++プログラマは人間のクズ、死ねよ
よく使われるマクロの置換ぐらいで目茶苦茶な反論してくるC++信者はキチガイだな。 そもそもCに寄生しないと生きていけないC++のくせにw
C++信者はキチガイ 近寄るべからず
要するに 「俺よりバカなヤツと、俺より頭の良いヤツ(俺の理解できない手法を使う)は来るな」 という意味だよな。
407 :
デフォルトの名無しさん :2009/02/27(金) 15:41:07
真・スレッドリスターター。。。( ̄ー ̄)ニヤリッ
409 :
デフォルトの名無しさん :2009/02/27(金) 17:23:29
真実上げ
C++厨は無闇にマクロ嫌ってる奴が多いけど 正直連中が使ってるテンプレートなんかよりCの素朴なマクロの方が ずっと明快だし、安全だし、高速だし、使いやすいよな
マクロ安全だと思ってるCプログラマはいないだろ ロベールさんだって怖いって言ってたよ
>>411 テンプレートにたいして明快だと思えない人間に、マクロトリックを使ってほしくないね。
マクロは複数行で \ つけるのが鬱陶しい
>>415 エディタがマクロの範囲を判断して適当にくっつけてくれるだろ?
>>415 鬱陶しいなら、改行文字と同じように、¥も非表示にすればいいんじゃね?
可変引数テンプレートを実装する為とかforwarding problemの解決の為にマクロは必須 C++厨というかテンプレート厨は同時にマクロ厨でもある
マクロがテンプレートより優れている4つの理由 #明快さ マクロの意味はマクロ名だけで明確に決まるので、定義を追いやすい。 また、大抵のコンパイラではプリプロセスだけ行うことができるので実際にどう展開されてるか確認できる。 引数に依存した複雑な推測をコンパイルと一緒にやってしまうテンプレートにはどちらも叶わぬことである #安全 マクロは括弧を十分に付けることと、#undefや二重定義にさえ注意すれば、大抵は思った通りに展開される。 一方テンプレートが思った通りに展開されないのは日常茶飯事である。 #高速 マクロは単なるテキスト置換なので極めて高速に行える。 テンプレートはパーシングの負荷はもとより、再帰のせいで止まらないことすらある。 #使いやすさ マクロの定義はやりたいことをがそのままテキストとして書かれる。 テンプレートは特殊化、SFINAEを乱用した恐ろしく回りくどいコードになる。
安全 の項は何が安全なんだろ。
少なくとも型に関してはまったく安全じゃないな
さらに展開されてからエラーになることによるエラー箇所の特定の難しさ、と テンプレートがらみの鬼のようなエラーログ ユーザに対する負担はいい勝負だな
テンプレートはエラーが出ても意味不明で結局対処できないからな。 0xでエラーメッセージが改善されることに期待だ。
C++をろくに知らないC使いが文句言うだけのスレになってる。
>>1 のおっさんが、そうでないことを祈るしかないな。
文句いうなら対案を出せってか 少なくともGitに関してはCだけで十分みたいだから対案を出す必要はない むしろCだけでは不十分な具体例を出す必要があるんじゃないか
linusが知らないことはあるだろうけどな
>>425 >>1 のおっさんがLinusの言葉の一部を切り取って煽ってるだけ。
対案。
>>1 を以下に書き換える。
「唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったとき」
Linus
適材適所ってやつだよ。 Cが好きでCばっかりやるのは自由だ。 C++を批判するなら、C++を極めてからにしてくれww まともに使えないウンコがいくら集まってもウンコなんだよww
C++って「ぼくのかんがえたさいきょうのげんご」的な厨房臭さがあるからなぁ
最強言語?なにそれ・・・ばっかじゃないのww
最強言語?なにそれ・・・ばっかじゃないの?ww
>>431 ,432
アンタがどこかしら弱いのだけはよく分かった。
あ、めんごめんご、ウンコ以下ですね
>>418 どっちもC++0xでマクロ使わずに解決しようとしている辺り、
C++陣営はよっぽどマクロが嫌いらしい。
しかし、マクロなしではどうせやっていけるわけないのだから、
ようするに単なるツンデレだろう。
インクルードガード以外にマクロは不要
438 :
デフォルトの名無しさん :2009/02/28(土) 16:46:42
ライブラリやシステムコールでマクロ使いまくり そもそもC++でCの機能使いまくりのC++厨は死ねよ
その理屈はよくわからない
440 :
デフォルトの名無しさん :2009/02/28(土) 16:59:31
C++厨はマクロの__FILE__や__LINE__使ったら自殺するらしいw
boostのassert系の関数では使われまくってるな
でもさ、移植性を気にして #ifdefでマクロをバシバシ切り替えているのって結構あるぜ。 あれ超ウゼー。
Cで移植性の高いプログラムを書けるのはひとえに#ifdefのおかげ あれなしに別々のコンパイラ特有のコードを混在させることはできない
Linusクラスの人間がC++プログラマはウンコっていうなら納得するが おまえらに言われてもな。おまえらがウンコだろって言われて終了。
>>437 おれはpragma once好きなんだけど、みんな嫌がっているんだよな。
この辺の変なこだわり(色々と理由があるのは理解するけど)が
C++のいやらしいところだなあ。と思ってみたり。
pragma onceを万が一インクルードガードに 書き換えなきゃならなくなったときのことを考えたら、 そりゃ嫌がられるさ。
両方書いとけばいいんだよ。 面倒くさい?全くもってそのとおりです。
448 :
デフォルトの名無しさん :2009/02/28(土) 21:51:58
釣りのためにLinuxまで作ってしまったLinusだが、Gitでは逆に作ってから 釣りあげられてしまったね。 笑える。 因果応報だよ。
何故 C++ で書かれたバージョン管理システムが普及しないのかを考えたほうが いいのかもしれない。 monotone くらいか?
C++のバージョン管理システムなんて恐ろしくて使えるか バージョン管理システムのバージョンを管理するシステムが別に必要になる
要は MFC 使ってた奴等が 「C++ 出来ます!!!」 って、大量に蔓延ったのが問題なだけだろ?
>>450 SCIMとscim-bridgeを思い出したw
ゲーム業界でのC++馬鹿はひどい。 どっかの本に書いてあったことを理解せず妄信してまともに動作しないものばかりつくってる。 特に大手の勘違い野郎に多い。 Cのころのほうがまともだった。これはコード量の問題ではない。
例えば?
組み込み有限メモリでガベージコレクション期待してるとか、 必要でもないポリモーフィズムつかって追跡性落としたりとか、 平気でシングルトンパターン使って自慢げな顔してたりとか。
>組み込み有限メモリでガベージコレクション期待してる それC++馬鹿なの?
エンジニア(SE とか マも含む)にとって一番必要な資質 新しい物見かけたら 「ドライバー(ねじ回し)持ってきて!!!」 てな、感じの好奇心 > どっかの本に書いてあったことを理解せず妄信 エンジニアではない
>>458 まあほとんどエンジニアなんていないってことだな。
本に書いてあることが正しくて現実を理解しようとしない。
その前に本すら読まない奴はエンジニア以下だけどね^^
達人プログラマーには技術書とそうでない本を月に一冊くらいずつ読めみたいなこと書いてたな。 自分の技術に投資し、自分の畑以外の知見を広げる努力ができなければエンジニアではいられない、とね。
愚者は経験に学び、賢者は歴史に学ぶ 経験=ドライバー(ねじ回し) 歴史=どっかの本
頭でっかちで自分では何も出来ないやつに人気のC++
技術はプライベートで検証してから導入してください。 おまえのオナニーでデスマとかありえん。
どっかの本を妄信している人間を「それは妄信だ」と断じるなら 少なくともその「どっかの本」くらいは読んでいて当然だわな そうでなく他人に妄信だというなら おまえ自身が妄信しているのだと
頭小さいけどモノつくれちゃうから収入多くて困っちゃう。
俺は難しい本を読んでる!とか思ってるやつとかホント使えん。 普通はパラパラって目を通せばその本の価値くらいわかる。
学びて思わざれば・・・じゃないが 本で学び、己で考え、経験して確かめる。 何事も中庸の徳だ。 本を読まない奴はエンジニアじゃないし 本を読むばかりで自分で考えようとしない奴もエンジニアじゃない。
本を妄信するにせよ、経験を妄信するにせよ とりあえず、現場ではビッグマウスはやめて心にしまっておけといいたい。 特に若いなら。
>>462 中がどうなっているか知ろうとする好奇心が必要なのであって
その好奇心すらない奴は
「経験からも歴史からも何かを得ようとはしない」
と言ってると思うんだが
お前らよっぽど本読みたくないんだなw せいぜい「経験」とやらを積んで、俺の職場には来ないでくれ。
>>468 よし、お前には孔子の名言をプレゼントだ。
学びて時にこれを習う、亦た説ばしからずや。
もちろん、お前は孔子より偉いに違いない。
やっぱC++信者はおかしいわ
Linuaは「C++プログラマはウンコ」って言ってるけど どう考えても奴の文章からは本をいっぱい読んでるように見えるぞ。ん?
>>471 そういうことだね。知的好奇心ないやつはエンジニアには向いてない。
知りたいことがあるから本を読む。
本を読んで疑問に感じたことを確かめずにはいられない。
だんだん派遣が夢を語るスレになってきたな こんなところで御託を並べる時間があったら、本読んで指動かしてプログラミングしろよw
>>477 > 本読んで指動かして
本の内容を理解してないんだったら意味がないわけだが
まぁ、何をどういおうと、本を読まないことのいいわけはできない。
>>478 その通りだよ
でも、上の方でねじ回し使えとか、経験が云々とか抜かしてる奴がいるからさ
そいつらの言う通りなら、そいつら自身が先ず指動かせよってことで
481 :
デフォルトの名無しさん :2009/03/01(日) 02:16:57
>>480 >>454 が
> どっかの本に書いてあったことを理解せず妄信してまともに動作しないものばかりつくってる。
言ってることが発端なんだから本を読めの指摘はおかしい
本に書いてあることを理解しようとする好奇心は必要
つか、ねじ回しにしたって好奇心が必要って意味での*極端な*例だと思うぞ
>>481 だから、他人に本を読めだの、ねじ回せだの言ってる奴に、まず自分からやれと言ってるだけだ。
>>482 彼らは自分からやってるかも知れないじゃないか?
私的感情や政治的理由で「決めつけ」する奴が、 エンジニアに必要な、探究心などをの素質を 備えていると思う?
>>482 あぁ、その点は大丈夫。少なくとも本に関しては好きだからどっちゃり読む。
>>484 ねじ回しの方は
>>481 で指摘した部分に対して
好奇心(言い換えれば探求心?)すら持てないような
奴はエンジニアたる資質がないと言ってるだけじゃない?
正論だと思うけどな………
本の方は末端反射で的外れなことを言ってるだけだから
それでいいだろうけどさ
本に関してはw好きだからwww
あれ?もしかして、本嫌いなのに仕方ないから読んでる人? かわいそうに・・・勉強するのつらいでしょ、それじゃあ。
俺も本好きで読んでるな。 好奇心とか特に考えず、活字がないとものたりないっつーか。 俺の周りでは月2,3万本代使うのが普通の連中しかいない。
まだ本を読まないこと正当化しようとする奴がいるのか?w
このスレは本を読まないクソだらけ、と。^^
どの本といわず、ただ本を読め、ってナンセンスだろ 矢沢なんとかの糞本でも何かプラスになるって言うのか?
つうか、深夜まで2chやってるやつが本よめとか馬鹿みたい。 その時間にお前が本嫁よ。 本読みながらやってるとしたら、集中力なさすぎ。
本読め、本読めと2ちゃんねるに書き込んで、今日も本を読まずに1日終える こんな生活が早3年 いつになったら俺はソフトを作れるのだろう そうだ、本を読んで、技術に興味を持てばできるはずだ 2ちゃんねるのみんなにもこのことを伝えてやろう (上へ戻る)
お前ら本読んで、技術に興味持てよ。 俺は本が好きだから毎日本読もうと思ってるから、明日から読むよ。 技術も大事だから、プログラミングは明後日からだ。 じゃあ、明日に備えて今日は寝るか。 (上へ戻る)
とりあえず2chブラウザとGUIのブラウザをアンインストールすることから始めないとな
なんだ、2ちゃんねるに書き込む人は本を読まない人なのか? 一服の清涼剤にここで毒を吐くくらいいいじゃないか もちろんほかの時間は本読んでるよ 今日読んだ本はExceptional C++の項目16〜24まで え?それしか読んでないの? はっはっは・・・最近疲れが溜まってて
>平気でシングルトンパターン使って自慢げな顔してたりとか。 いろいろオレに当てはまってる気がするんだが、シングルトンパターンが非常に危険で使いどころが 難しいというなら具体的に指摘してもらえるとありがたいが、こんなスレじゃ無理かw ゲームみたいな組み込み系に近い開発なら普通に有用だと思うんだが。 Cでコード内にstaticで保持したワークで処理を書いたほうがより無難といいたいんだろうか。 初期化コードや終了コードの呼び出しの手間だけでもシングルトンのがマシだと思うけど。
シングルトンが正しく動くかどうかはメモリモデルに強く依存すること シングルトンクラスが複数あると大抵ろくなことにならないということ マルチスレッドとシングルトンの相性は最悪だということ この辺をちゃんと理解してるなら使ってもいいと思うよ
シングルトンは羊の皮をかぶったグローバル変数だってサッターが書いてた。
あ、ちなみに僕はシングルトンパターンよくわからんです。今勉強中ですが。
>>498 とりあえずお前はゲーム業界には来ないでね
ゲーム業界に居ない奴が、来ないでね、という不思議。
シングルトンについての個人的な意見だが、 クラスをまたいで同一のシングルトンを操作すると、クラスが癒着してしまって切り出せない構造になってしまう。 それがOOなのかはよく知らない。 継承するくらいなら、委譲したほうがいいし。 クラスの設定とかをするなら小さくまとめて、コンストラクタや初期化メソッドあたりで設定してしまうのがいいと思ってる。 用途が同じでもグローバル変数はもちろん使わないがメンバ変数は大いに使う。ポータビリティの違いがそこにある。
まぁGitはグローバル変数使ってるんですけどね
グローバル変数はヒープとは違います。
>>499 シングルトンでスレッド制御してるし、シングルトンによるハードウェアリソースの管理で10個以上存在してるし
キミのいってることは具体的な例がないとオレには理解できないみたいだ。
>>500 オブジェクトが開放されるとせいぜいポインタ分しかメモリ使わないけど?
>>502 10年遅い。
>>504 単一機能の処理をシングルトンで実装してるわけだから、継承とか関係なくね?
まさかすべてのクラスがシングルトンかそうじゃないかって話してんの?
何人いるのか判らんがレベル低いね。
恥ずかしい奴
>>504 がこの流れで
「継承するくらいなら、委譲したほうがいいし。」
と言って見せたのは、誤解を受けそうではあるものの、
なにか、静かに同意できる。
継承よりも委譲がなぜいいか、が、
シングルとンがなぜまずいか、とちょっと似てると思う。
可能な限り癒着せずに、
プリンッとした明白な状態をたもっていたい。
というか、誰もシングルトンを継承するって言ってないと思うんだが
>>507 スレッド間にも各ハードウェアリソース間にも初期化・解体の順序性が一切なく完全に独立してるならいいと思うけど
相当特殊な環境じゃないとそんなことなさそう
もしその10個に順序性があって、使いこなしてるなら本当に凄いと思う
安全性を保つためにどんだけカオスなコードが必要になるか想像も付かない
俺のような凡人は2つでもお断りする
字面を眺めただけで本を読んだ気になってる奴。 処理内容をほっといてシングルトンだけで云々。 単なる道具であるC++程度も使えないウンコでさえ、 ウンコと言いたくなる気持ちは判るなぁ
C++で機能が増えた分、設計の自由度は上がる。 その自由度を最大限使った設計をすることが 良いことかどうかはまた別の話。
だからこそ、保守性の高いCが使われるってことで
良くも悪くも枯れてるから。
Windows OSとしてはCはサポートしてないよね Windows自体は主にCで書かれてるけど
闘うプログラマーには最初のWindows NTはC++で開発したって書いてあったけど 今のWindowsは違うのかな?
何故違うと思ったの?
以前はboostに入ってるいくつかの美しくないライブラリを平気で使っていたけど ここまでして他の言語真似するなら、他の言語でよくね? と思ったので今では仕事以外でC++使う機会は0 まぁ、0xの標準ライブラリに組み込まれるものがあんなに醜いのだから C++プログラマーはウンコなんて言われても仕方ない…
>>519 他の言語のまねの部分なんて、boostのほんの一部。
適当にググって話作ったでしょ?
operaror&がshared_ptrを戻すようにすれば少しは美しくなるのにな。
>>520 話をすりかえるなよ…
真似てない部分も醜い
というか、真似じゃない部分に関しては
他の言語では不要なものばかりなんだよな
言語機能の不足をテンプレートライブラリでカバーするアプローチそのものが醜い
>>522 他の言語で不要なんじゃなくて、自分の使ってる範囲で不要なんでしょうに。
言語とライブラリの関係については、C言語の時以来の伝統。
このスレで言っても始まらん。
524 :
デフォルトの名無しさん :2009/03/04(水) 14:08:08
多倍長整数と正規表現リテラルとスマートポインターを第一級オブジェクトにして欲しいな。 構文がだらだら長くて汚すぎ。
>>522 じゃあ、お前は使うな!まぁ、言われなくても使ってないだろうけど。
はい、終了
>>524 こうか?
int main() {
regex^ pat = /hello/;
cout << "hello, world".gsub(pat, "hell") << endl;
return 0;
}
528 :
デフォルトの名無しさん :2009/03/04(水) 15:41:30
C++は多言語の真似ばかりでしかもウンコ汚ね。
529 :
デフォルトの名無しさん :2009/03/04(水) 16:07:01
Linusさんって、あんな誠実そうなお顔をして、かなり口が悪いんだなあww さすがの2ちゃんねらーも顔負けって感じww
Linusに限らず、技術者は大体口が悪い。 Effective C++ 読むと嫌味満載だし デスマーチとかグチばかり。
C++での糞案件にひっかかったら性格歪んで当然だな
Linusさんはそんなに視野狭くないと思うよ。
534 :
デフォルトの名無しさん :2009/03/04(水) 17:30:23
ここのアンチC++はLinusに釣られすぎ。 Unix互換OS作ってるんだから、OSの機能は当然C互換にならざるを得ないし、 C++で作ってもオモテに出すAPIはextern "C"した関数になるしで、 内部で完結する要素にしか++部分を生かせないんだからCでつくりゃいいわけよ。 こんなことすら想像できずに、C++にしないの?とか聞いてくる奴には説明しても無駄だから 糞はこっちくんな とののしる方が手っ取り早い。 真剣にCとC++の優劣を論じるだけ無駄ってもんだよ。
>>534 Linuxの話じゃないんだがw
1くらい読めよ
やっちまったなあ
リーナスは結構ツンデレだから・・
Linus 「さんをつけろよデコスケ野郎!!!1」
それをいうなら、Gitも、CLIじゃなくてGUIで、 といった途端に、C++やらObjective-Cやらになっちゃうんだけどね。
スレの内容を総括すると、Linusが仰るように やっぱり、C++はウンコ っていうこと決定しました。
>>539 window system に X 使うんだったら C++ も Objective-C も必要ない
>>523 > 他の言語で不要なんじゃなくて、自分の使ってる範囲で不要なんでしょうに。
いやいや、スマートポインタやanyみたいに他の言語では不要なものが沢山あるだろうよ…
>>541 言いたいことは分かるけど、
OS XやらWindowsやらで独自にGUIをつくろう、となるのは、
X用のgit-tclが使いにくいからでしょ。正直。
>>542 スマートポインタは標準に取り込まれたからBoostがうんぬん、と言う話でもないし。
anyは他の言語では実現できないから用意されてないだけ。
実現できないからではなく必要がないと言うべきだろ。 anyは普通の動的言語なら当然のこと。 JavaとかC#だってObjectで同じような目的を果たせる。 スマートポインタだって「他の言語」ではGCあるから要らないって言いたいだけでしょどうせ。 こういうのがライブラリになっているC++は、不要なら使わずに済み、 必要ならCよりはましに使えるというのが売りの1つのはず。 さっぱり売りになっていないという主張は認める。
>>545 Objectに相当するのはanyじゃなくて「void *」。
anyは型安全性が入ってる。
スマートポインタは、ヒープの管理+所有権の管理。
共有したいならshare、所有権を明確にしたいならuniqe。
>>546 Objectだって元と違う型へキャストすれば例外が飛ぶんだから、
anyのような一面も持ち合わせていると思うんだがな。
>>547 あ、そっか。
じゃあ、「Object v = 1;」ができて、
「.close()」とか「.dispose()」とかが要るクラスでも安全に使えるようになったら
認めてあげる。
549 :
デフォルトの名無しさん :2009/03/05(木) 01:04:40
そんなクソ言語になるわけないだろ。
>>548 そんなもの必要がない場面だからC++が選ばれないんだよ。
いやまあ裏を返して、そういう必要性があればC++使われるのかと言えば、
そんなことないのはそのとおりなんだけど。
C#でおk
>>550 そうやって、車輪の再発明に勤しむのも結構。
車輪がすでにあることを否定しなければ。
553 :
550 :2009/03/05(木) 01:59:46
>>552 いやねえ。俺はC++使っているよ。そこが便利だと思ったから。
>>553 ごめん。
てっきり、このスレに跋扈してる、C++をろくに知らずに
批判する人たちのナカーマだと思いこんでたよ。
556 :
デフォルトの名無しさん :2009/03/05(木) 19:17:35
C++を知ってるなら他人にはすすめんよ。 人生の貴重な時間の無駄だからな。
アンタには勧めんよ。無駄だからな。
モバイルに持っていくことを考慮してC++を選択してたのも今や昔…
今のゲームは大抵C++だよ
C++のゲームプログラムなんてほとんどがプログラマーのオナニー。
オナニーならぜひ見てみたい。
上手く書かれたプログラムなら、他人が書いたソースを読む必要は無い。 でも、そういう場面は稀で、ソースを確認したい衝動に駆られる。 その時、イヤな思いをするのは、圧倒的に C で書かれたライブラリより C++ の、それだ。 言語の優劣というより、思想がそうさせてるんだろうな。
フローを追うのが困難なんだよな 重要な処理が散らばってることが多くて Cに比べて当たりを付けにくい
その理屈だと小さい関数に分けまくってるようなHaskellとかMLは最悪になるだろうな
566 :
デフォルトの名無しさん :2009/03/06(金) 14:45:06
宣言と定義が別のファイルってマヌケとしか言いようがない。
まず、何のために小さく分けようとしているのかを考えろ 何も考えずに小さい=正義というのが最悪なのは当然だ
>>566 時代背景とCという歴史的経緯を考えれば仕方がない。
が、現代からすれば間抜けにしか思えないのは同意。
JavaくらいにIDEの支援が充実できていれば、
当然IDEが適当にヘッダを何とかしてくれるようになっているだろうと思うけど、
そんなの絶対無理だorz
ヘッダなんてコンパイラが自動生成してくれるべき
リーナス毒舌炸裂
Javaも、フラットなパッケージシステムが古くさくなったから、 パッケージ記述を別ファイルに書くように変わるんじゃなかったっけ。 スーパーパッケージだったか。
C/C++のコンセプトを否定してることにも気づかないほど低レベルなレス。
コンセプトなんてますますテンプレートをカオスにするだけだろ エラーメッセージの改善なんて信じない
コンセプトはアサーションみたく エラーメッセージの改善に役立ってくれると思うけど。 コンセプトマップが導入されたらどうなるか想像もつかない。
まあ使いたくなかったら使わなければ良いんじゃね。 マクロよりまともな文法で冗長な記述が減らせるから フローを追うのも慣れればCより楽だろ。
>>573-574 言語学ぶ前にまず日本語読解力から身につけたほうがいいような...
それともこれが知らない言葉が出てくるたびに
ググレカスいわれつづけた2ch住人の末路ですか?
>>576 日本語の前に空気読めるようになった方がいいよ。
C++の話をしてるときに、コンセプトっていったら何を意味するか
理解しない/思いつかない人にC++の講釈は受けたくない、ってこと。
その言葉... そっくりそのまま返せるのはこっちのほうなんだが…
>>572 てゆうかC言語にコンセプト(機能の方)ってあんの?
>>578 違うわボケw
と言えば終わりだったのにってことでしょ
わろた。まさに低レベルw
583 :
デフォルトの名無しさん :2009/03/07(土) 14:15:06
自分で書いたネタをいちいち釈明する痛いC++厨が住むスレ
本当は関数型言語が最強なんだが 低脳じゃ使えんからな だからな、低脳用にC/C++みたいな言語容易してるんだ
関数型言語というだけあって抽象的だなあ。
>>584 おまえは一生関数型言語使ってりゃいいよ
まわりが不幸にならずにすむ
587 :
デフォルトの名無しさん :2009/03/07(土) 20:54:30
なんでC++なんかでプログラミングするの? 「それがぼくには楽しかったから」さw
588 :
デフォルトの名無しさん :2009/03/07(土) 20:59:19
C++から例外とかを除けて、C++--を作ればいい
RTTI が必要になること自体、普通は設計に問題があるかんね。 まあ、やむを得ない場合もなくはないが・・・。
Google は例外を否定しているわけじゃないようだね。 例外安全でない過去の資源があるからしかたなくという感じだ。
enumの変わりに構造体とRTTI使ってた俺は異端ということか……
GoogleにもLinusさんみたいな人がいて、 Cから(安全に)呼び出せないコードは許さん! とか言ってるんだろうか。
>>594 Java 1.5のEnumと同じようなの作ろうとしたら構造体とRTTIになるんだろうね。
595 :
594 :2009/03/07(土) 22:17:31
596 :
594 :2009/03/07(土) 22:19:35
関数型言語最強とか言ってる奴はプログラマーじゃないだろ。 もしくは人と接触しない変態。
Windows全盛だから、Windows以外でプログラム書く奴って何なの? って言っちゃうタイプだろうな。 良い悪いは別にして、広い視野を持つことはプログラマにとって 大事だと思う。
>>597 そういうこと行っているおまえは
関数型言語使ったことあるのか
600 :
594 :2009/03/07(土) 23:34:01
>>597 MSも関数型言語には注目してるみたいだよ。
VC2010にF#が入るらしいし。
どこまで本気か知らないけど。
.....それって、要望あるからVSサポート言語にするのか?
C++もboostで関数型っぽい道を模索してるくらいだし、注目はされてるんだろう。
603 :
デフォルトの名無しさん :2009/03/07(土) 23:59:38
Cにあったシンプルさがまったくなくなってるんだよな まだEC++のほうがまし
604 :
594 :2009/03/08(日) 00:00:21
並列化しやすいんだって。 べたなOpenCL/DirectXのような並列化と、抽象度の高い関数型言語による並列化と、 どっちがはやるかなあ。
605 :
デフォルトの名無しさん :2009/03/08(日) 00:02:45
並列化だけなら静的変数に制限すればいいような気がするんだが。
でもよ、Cってクラスライブラリ使えないだろ これが俺的には最大の欠点だな Cはクラスライブラリを使わない分野にしか活路がないような気がする
607 :
デフォルトの名無しさん :2009/03/08(日) 00:05:00
おまえが「クラスライブラリ」って単語使って何が言いたいのかさっぱりわからん。
608 :
594 :2009/03/08(日) 00:20:27
>>605 static?のことだったら意味分からん。おせーて。
constのことだったら、C#は将来デフォでconstになるかもよ。
C#の話はしてませんから。
610 :
594 :2009/03/08(日) 00:39:16
そうかなあ。関数型言語の話が振られてるときに、 C言語に持っていくのは難易度高いぞ。
611 :
デフォルトの名無しさん :2009/03/08(日) 01:11:07 BE:871718764-2BP(182)
>>606 GTKはクラスライブラリだと思うけどな。
少なくともC++がオブジェクト指向言語というのと同程度には。
コピペ君って馬鹿だな、まで読んだ。
614 :
デフォルトの名無しさん :2009/03/08(日) 03:04:29
この際、有志で HSP を叩き台に HS++(hspp)を作ったほうがいいんじゃないかと思うんだよね。 HSP にオブジェクト指向をプラスして、低レベルな API を整備すれば 少なくとも C++ よりはマシな言語になりそう。
無茶言うな
616 :
デフォルトの名無しさん :2009/03/08(日) 04:38:42
ばかだろ
Cの正当な後継者はJavascriptだと思うよ。
いや、やっぱD言語だろ
Cで満足されてるし後継は無しで
haskell使ってても結局パフォーマンスが必要なところはCだからな ここぞとばかりにunsafePerformIOが使える楽しいところでもある
2つの言語が混在したコードをメンテするのは それなりに面倒だけどなあ。
その理屈だと扱う言語が2種どころじゃないwebアプリ(笑)なんて地獄だな
configureとMakefileの悪口は・・・もっと評価されていい
>>622 HTMLはさすがに(プログラミング)言語にはカウントしたくないけど。
MacもObjective-C使うから地獄だな
Objective-Cかっこいいじゃん。
webアプリ屋さんは大変だよなあ 2種類どころか1ダースって感じだし
最低限でもHTML,JS,Perl,PHP,Python,Java,SQLくらいは必要なのかな? 大変だなぁ
>>628 Perl, Python, Java は全然最低要件じゃないだろw
開発体制とか顧客との関係にもよるけど
C, PHP, JS, HTML(の正確な知識), SQL, AS ぐらいかな。
俺は速度を求める部分は C, 他は PHP。
業務上、用途の被る言語を無駄に覚えなければならないとしたら
開発体制・営業戦略に欠陥があるだけ。
勿論、できないよりはできるにこしたことはないけど。
実際、速度を求めてCで書くのって、どんなのがある?
各種スクリプト言語のFFIを利用するとき
「自分の使う言語はこれ。それ以外はシラネ(うんこ)」 ですね。勉強になりました
「何も考えず言語をあれこれ。ノウハウの蓄積なんかシラネ」 ですね。毎日デスマご苦労様です
90年代の前半からカーネルをC++で書き直すべき みたいなうざいやつがMLにたびたび沸いてたからなあ
web屋は技術の入れ替わりが激しくて技術が蓄積しづらい印象がある プログラム技術全体に言えることだけど
この世にはC+-って言語があるのか? 今日部屋を掃除してたら以前ハロワでコピーした求人票が出てきて、 仕事の内容の欄をよく見てたら C+- って書いてあるのがあったんだが・・・
それ C
638 :
デフォルトの名無しさん :2009/03/08(日) 20:40:59
C++プログラマ「Linusはウンコ。寄ってくるな」
俺の認識では 「C++ 使えます」 ≒ 「MFCでプログラム組んだことがあります」 実は, C++ 使えない奴の方が圧倒的に多い
俺の認識では 「C++ 使えます」 ≒ 「Qtでプログラム組んだことがあります」
C++使えるって奴でも、MFCのコードを見て 「こんなんできねー」って絶望する人は多い。
>>641 俺も思うよ。
「何でこんなアホなモデリングしてるんだ?」
って
というか、今C++使う意義なんて高機能の割に 互換性が高い、ぐらいしかないから。 というかboostとかも含めその方針だし。 中途半端にMFC使うぐらいならC#でいいしなあ。 C++使っててQt, wx当りのクロプラTK使ってるならまだわかるけど MFCとかは確かに「寄ってくんな」って感じだな。
644 :
デフォルトの名無しさん :2009/03/08(日) 21:14:07
馬鹿しかいないな
生半可な知識しかもってない人ほど断定口調なのはなぜ?
自称生半可じゃない知識をもってる人がそういう奴を論破できないほどヘタレだから
なるほど。論理的思考ができないからか。参考になった。ありがと
煽りにマジレスみっともない
いや、いつも「できます」って言ってくる営業の人思い出したんだよ。マジで
いや、いつも「ちゃんとしたのできます」って言ってくるPG思い出したんだよ。マジで
651 :
デフォルトの名無しさん :2009/03/09(月) 00:42:06
ワーキングプアww
ということは馬鹿な俺はとりあえずシープラプラでおkということか
イマドキC++って・・・(笑) やっぱCocoaでしょフツー
654 :
デフォルトの名無しさん :2009/03/09(月) 09:32:51
釣りにしても酷いな
やっと
>>1 のおっさんにふさわしいスレになってきた。
Linusが言いたかったのは Linus「Cプログラマ以外はウンコ。寄ってくるな」 だろう。
なんでC++でやらないんですか?C++の方が簡単に出来るのに何でしないの? と聞かれるのがうざかったんだとおもうなー
C++の方が簡単ってのはないだろう というか、あえて複雑にする傾向にあるよな、C++好きの人。 関数1行で済むことにも、まずクラス作ろうぜ、だって再利用することが あるかもしれないから、とか言って、骨組みだけの内容の無いコードを書くよね
関数1行で済むことにも、まずクラス作ろうぜ ぽかーーーん
660 :
デフォルトの名無しさん :2009/03/09(月) 22:07:03
>>658 まったく的確な指摘なんだが本人に自覚ないから気づくこともない
再利用可能性そのものは重要だと思うけどね
2chでいうと、スレが続くと思って Part 1スレを立てちゃうみたいなもんだな
>>634 C#やObjective-CみたいにOSの後ろ盾が欲しいんだろうな
664 :
デフォルトの名無しさん :2009/03/09(月) 22:19:26
それは必要にならないって奴? ところで、グローバル関数はグローバルな名前空間を汚染するので C++ではクラスを使ったり、無名の名前空間の中に押し込んだりするのが一般的・・・だそうな。
原理主義者のやることは、どの言語のそれでも似たようなもんですわ どうやれば、そんなに頭が凝り固まるのか感服することさえある
それはスコープを限定することに神経質にならないと、ADLがらみで酷い事になるから この部分にかけてはもう欠陥といってもいい程わけわからんことになってる
今度から part 2 から始めるよ。
テスト
Visual Studioで組んでると、ネームスペースで細かく分けるのに意味がある インテリセンスは便利だ... 可愛いよthis、可愛いよthis...
でかいクラスを作らず小さいクラスをたくさん作るのはなんで? ごめんねウンコプログラマでCでハード系組んだこともなくてごめんね
>>673 部屋の整理術みたいなもん
大きな箱に物を詰め込むと大概ちらかる
>>673 多くの場合、小さいほうがシンプル
命名するのがマンドクセーのが唯一欠点
Cで大きな関数を作らずに小さい関数を沢山作るのと同じようなもの
その作ったたくさんの小さなクラスをまとめるのに構造体を作って 結局でかいデータ構造体ができてるおれ
まず小クラスで細かく色々作って、実際使ってくうちに 組み合わせて大クラスへと変貌してく。
Cで関数が大きいとかで悩むことってほとんどないよね オブジェクト指向が変なテーマを持ち込んだもんだ
682 :
デフォルトの名無しさん :2009/03/15(日) 10:19:03
基本 関数は画面1ページに収まるようにしましょう。
>>682 GNUにあがってるソースを見ると、守ってない人多いよね。
守るもなにも一ページうんぬんって、まあ、宗教だからな。 そういう宗教人じゃないと関係ない。
最悪の場合、複雑に絡み合ったままの状態で形だけ分割して別々のファイルに書く。 要は、分割するとか1ページに収めるとかいう漠然とした言葉では 正確な意味が伝わらない罠。
Code Completeで、ルーチンの行数とエラーとの関係の調査結果が いくつか載ってるけど、200行以下の場合は行数が少ないほど、一行 あたりのエラーが増える(100行のルーチン一つと10行のルーチン10個 では、10行のルーチン10個のほうがバグが多い)とか、ルーチン行数と エラーに因果関係はなくて、構造的な複雑さやデータの多さに関係 してるとかって「関数は小さいほうがいい」みたいな説に反する調査 結果ばかりだな。 行数じゃなくて、複雑さに着目しようって結論 > Code Complete まあ、行数が多い関数は複雑さも増してることが多いだろうから、 すごい初心者には行数でアドバイスするのは有効かもしれんけど、 教条主義的に行数制限すると、かえって素直なコードじゃなくなるよな。
200行の読みやすい関数と、40行の関数が5個の読みにくい関数だとどっちがいいんだ?
全く別物を比べても意味がないだろう
690 :
デフォルトの名無しさん :2009/03/15(日) 12:15:43
>>685 それを言ったら、コーディング規則なんて全部宗教だろ。
信じて救われる人間がいるから、多くがそれに従う。
極論ですね分かります
極論?
>>683 画面1ページって何行かしらないけど、全関数が30行とか50行以内に収まってる
のって、GNUだけじゃなくて、まともなプロダクツじゃ皆無だろ。
haskellだと30行でも長すぎって感じるようになるよ
BASICで一画面プログラムとか懐かしいのぅ。 しかも、MSXの40x24でマトモに動いたんだから凄いね。
1画面に納めるためになるべく改行を減らしたりとかあったなぁ。 見難かった
697 :
デフォルトの名無しさん :2009/03/15(日) 13:41:06
どんな有用なルールでも無知な人には理解できないから、 ちんぷんかんぷんで宗教のように見えるってことだろうな まあ無知な当人には理解できないんだろうけど
>>689 が宗教を理解できていないことはわかった。
>>699 40行の関数が5個の読みやすい関数が一番だろ
> 200行の読みやすい関数と、40行の関数が5個の読みにくい関数だとどっちがいいんだ? ちょっと別の話だけど、 200行の関数を五個に分けたとき、 トータルはきっと200行以下になるよね? 共通部分を抜き出して再利用するってそういうことだよね? つまり、分けていくって作業は、 トータル量を圧縮していく作業でもあり、 全体の複雑さを減らす作業でもあると思うんだ。 宗教以上の効果があるんじゃね?
いんや 処理に名前をつけるという意味もあるから増えることもあるよ
703 :
デフォルトの名無しさん :2009/03/15(日) 15:04:35
というか、関数自体がオブ指向ダヨネ。 素のコードを引数以外隠蔽して概念化するためにあるんだから。 ここらへんに気付けてるのってもしかして俺だけ?
ホーア論理の考えでassert入れてけば200行の関数が大抵数個の組に分けられるから それを参考に小さい関数に分割できる こうやって分けるメリットの一つは自動化された単体テストができるようになること これは大きい…
ニンジンを切るように三つに魚を切り分けるのと、 再利用性を考えて三枚に下ろすのとでは違うよね。 でも、長いタスクをあいまいにニンジン切り分けするときってあるよね。
706 :
705 :2009/03/15(日) 15:17:00
いや、俺は何を言っているんだ。
ニンジンと魚の三枚下ろしでなにができるかな!!
コーディング規約は何がより望ましくて何がそうでないかの境界がはっきりしないことが 確かに多いけれど、だからといってそれを宗教だというのは 役にたつ規約とそうでないものは判断の境界が曖昧だからどちらも役に立たない という滅茶苦茶な論になっているのに気がつかないのか? ナイーブすぎ
関数の行数制限とか、比較のときに定数を左に置くとか、ああいうのは宗教だよな。
>>708 たとえば2chは基本的には役に立たない情報源なわけで
「役に立たないが一応コーディング規約がある」
ってスタンスは悪くないと思う
その土地のしきたりだから良いんじゃね
「宗教」という言葉に過剰反応している奴がいるようだが、 世の中では「コーディング規則」なんかより遥かに社会的に尊重されている行動規範が「宗教」 「コーディング規則が宗教」というのは、プログラマが従うべき行動規範としてのコーディング規則にとって何らネガティブな意味は無い。
宗教は神のような上位的存在に縛られないと マナーを守る事もできないような原始的な人達のためのものだな。
社会での宗教の重要性は、他人の宗教観を尊重できない土人には理解できないだろう。
日本ではプログラマのような下民に宗教は必要ないよ
ソフトウェア開発においてプログラマーより偉いやつっているの?
いるわけないだろ。 バグ仕込むのも、デスマ引き起こすのも、全部プログラマー様のお陰だからな。
モノつくれないけど卑怯に立ち回れる奴が勝ち組なんだよね。
比較の時に定数を左にって、段取りが明確なコードなら 比較対象の変数は自明なことが多いからそのほうが可読性が高い(意図を読みやすい)、 ってことだと思ってずっとそうしてた。 コンパイラに関係してるとは思わんかったな。今も反省はしていないが。
枝葉末節
宗教の中に合理性を見出す者は 哲学を作り、キリスト教を作り、ローマを作り。 名言スマソ。
>>716 いや、むしろ、開発でプログラマーより下のやつを知らないんだが。
FT専門のテスターが最下位じゃないかな。
一画面とかそんなこと意識して関数の大きさ決めてんの? ちょっと引いた それならワイドモニターを縦にして作業してればいいじゃん
>>725 わろた。
ほんとは自分低脳を隠すための言い訳
シグナルの一つとしては考えてる
関数を畳めるエディタ使えば別にどれだけ長くても問題ないだろ。
確かにその通りだな。 関数はmain()一つで機能は中でswitchで切り替えればいいね。
一画面以内って話のは、PCの画面が20行とか25行が主流の時代から
あって、当時そう主張してた人たちはマジでそれを守ってかいてたのか
すごい疑問。今考えると。
>>725 当時も、印刷したら一枚60行だから、60行までセーフとかって説があった。
一画面に入れるために改行ケチったりして 醜くなるなら逆効果だな。 一画面プログラムみたいなのはネタだけでいい。
一画面プログラムなんて話誰もしてないだろ
733 :
デフォルトの名無しさん :2009/03/15(日) 22:32:40
>>732 は日常ではしょっちゅう空気読めって怒られるタイプ
自分は行数あまり長くならないんだけど みんな何作ってるの?
普通は限界50行前後までと意識して、 どんだけ長くても100行以内にする 普通は30行以内で書く
Linusのgitのソースを見てみたら50行以上の関数はふつーにあった。
関数呼び出しコストもバカにならんよ! スタック消費量が減らない場合は関数なんて無駄に作るべきじゃない
関数呼び出しコストを気にして関数作らない奴に限って ソースの見通しが悪くて開発効率が悪く トータルでパフォーマンスや性能改善速度を落とす法則
コンパイラの最適化も大きな関数ほどよく効く
この問題は大きな政府か、小さな政府か、という問題に似ているな。 大きな関数ならばコードは安定するが、コードの流動性は低下する。 小さな関数ならばコード間に市場競争が生まれ、 新しいパターンを素早く構成することが出来る。
別に関数を大きくしても安定はしないだろ。
745 :
デフォルトの名無しさん :2009/03/15(日) 23:31:58
インライン関数たんの存在が忘れられてるな。 インラインならコンパイラの最適化オプション次第で 展開するかどうか微調整できるだろ。 …マ、マサカこんなところでC++の追い風になるとは…予想外の展開
関数呼び出しのコストが気になるなんてどんなスケールの開発だか想像できない。
747 :
デフォルトの名無しさん :2009/03/15(日) 23:53:24
>>745 もうこのスレでインラインなんて用語使わないでくれ
頻繁に呼ばれる関数が性能のボトルネックのひとつになるなんて よく事あるじゃん
頻繁に呼ばれる関数の「呼び出し」がコストに影響するなんてそうそうないんだけど。 staticつければ最適化がかからないコンパイラほとんどないし。 定量的なパフォーマンス計測してるの?
インライン展開は結構馬鹿にならない速度アップすることあるからな。
関数呼び出しがそれなりにコストのかかるものだってのは それこそ定量的に計測してりゃわかると思うんだがね
で何パーセント影響があってあんたのシステムでどの程度の時間を食ってるわけ?
だからこそ、インラインがC・C++で用意されてるんだよな
>>753 でも、今となってはインラインの速度面での効果なんてregister程度だろうと思う。
自分がinlineを使う基準は「ヘッダに書きたいか」としている。
上の方で宗教が如何こう言ってるやつが居るが... 何時の時代も、宗教があるから争いが起こるんだぜ
最適化の知識やコンパイル後のコードの知識が足りないだけだろ。
>>752 世の中、高速CPUで動いているプログラムだけじゃないよ
コストを抑えるため低性能マイコンを使って無理してパフォーマンス
出さなければいけない場合なんかでは必須
世の中お金持ちばかりとは限らん
ヘッダはプロトタイプ宣言とかクラス宣言だけにしろよ
>>757 >>752 に答えてよ。大体の数字で構わないから。
いまどきそこまで性能の低いCPUを使ってる環境も少ないぜ。
ARM以下の仕事なら俺にはわからんが。
>>758 そうしたいのは山々だが、テンプレートを使う場合は無理
使わなければいいと思う。
>>759 おまえPGじゃないだろ
世の中8bit・16bitマイコンいっぱい使われてるの知らんのか
>>762 そのサイズならアセンブラ併用だろ。
関数コールとかの問題じゃない。
いまどきの8bit/16bitってメモリ空間広いの? Cでコード書くくらいに
>>763 最近はほとんど使用しない。コンパイラの方が頭良い。
少なくても俺よりな。
組み込み用のコンパイラだと独自拡張で、IOとかも叩けるようになっているよな。 本格的にやっているわけではないが、アセンブラなくてもなんとかなることが多いと思う。
で関数コールに文句つけれる頭持ってるわけ? 本当に頭悪そう。コンパイラ出力くらい見てるだろ?
>>765 IO操作って基本中の基本操作なのに、それをアセンブラでなんてやったえらい手間
なんかレベルひくっ
>>759 えー、何言ってんだよ。
電子レンジやエアコンや湯沸かし器や炊飯器や冷蔵庫に、そんなに上等な
チップ載っけてるわけないだろ。
たぶんあなたの家にあるマイクロプロセッサの大半が、マイコンレベル。
そして、制御ロジックのほとんどは高級言語でコーディングされている。
771 :
デフォルトの名無しさん :2009/03/16(月) 00:39:29
いまだにC/C++をあえて使う必要のある環境じゃ関数呼び出しは気になるもんなのかね
>>759 小さなプログラム書いて呼び出し時間を計測してみなよ。
あと、関数の呼び出しコストはarmだろうがcore2だろうが、
それなりにかかるわけでプロセッサがどうのこうのは関係無い。
もちろん呼び出しコストを過大評価するつもりもないけど。
>>772 いやだから何パーセント程度を持ってコストかかってると判断するのよ。
あと実際にそれがどこにどの程度表面化してるわけ?
細かいところまで関数呼び出しにしたとしても
その程度の関数呼び出しならstatic関数で書き換えられて
最適化でパフォーマンスに影響しないだろ。
呼び出しコストがかかるのは通常のリンケージのタイプのもので
そのレベルのものを書くほうが面倒だよ。
だから俺の体感としてはよほどかかって5%以下という感覚。
>>770 >>759 は32bitのマイコン搭載の電子レンジやエアコンや湯沸かし器や炊飯器や冷蔵庫
の製品しか使ってない世界の人。
昔MIPS33Mhz程度で関数展開とかループ展開とかしてるコードあったな。 可読性上げつつアルゴリズム少し見直しただけでパフォーマンス3倍程度になった。
疲れた
>>773 コストと言うよりワーストケースのリアルタイム処理で支障をきたす部分が
出ればアウト。制御系では許されん。
関数呼び出しの問題からかけ離れてきたなw
オブジェクト指向バカは人間の可読性のことしか考えてないから楽だわな
局所的なパフォーマンスだけ見てる本物のアホ お前のコード遅くて使い物にならん
局所的なパフォーマンスもあがってないんだけどなw
局所的なパフォーマンスを軽視するのは 大局的なアーキテクチャを軽視するのと 同様に愚かだ
>>772 思い出した!!! 極端な例だけどな…
むかし、「はじめて 32bit RISC を使います」って連中と仕事したんだけど、
全然、動かなかった。
「何でうごかねぇの?」って、ソース眺めてみたら、アドレスエラー回避のために
そこいらじゅうで 2byte とか 4byte の memcpy をしてた。
呼び出しのオーバーヘッドの方があからさまにでかいわなwW
ハードプログラミングでCって結構使われてるのね, ところで組み込みプログラミングというのは プログラムでメモリ管理から通電の挙動まで制御するのをいうんであって 機器にlinuxつっこんでlinux上で機器の制御するのも組み込みプログラミングとは言わないの?
どっちも違う
組み込みって自分でI/Oを制御してプチOSを作るんだろ?
>>786 OSなしっていうのも多いけど、
OSを一からフルスクラップするぐらいなら既存のOSを使うよ。
フルスクラップ
789 :
787 :2009/03/16(月) 09:36:26
自分で書いてて声に出して笑ってしまった
スクラップアンドスクラップ ! すべてをぶち壊すことだ! もはや政府転覆しかぬわぁぁい!
>>790 なつかしいな。
そんなの、すっかり忘れてたよ。
C++プログラマは言語から受けるストレスと ストラウトラップの呪いて禿げる。
C++プログラマがうんこにしかならないのはなぜか?
どおりでC++プログラマにハゲが多いわけだ
>>795 いい加減なことを言うなよ。ウンコがハゲやすいなんて、聞いたことがないぞ。
というか、ちゃんと消化されてれば元々ハゲてるだろ。
ははは
inskapeはc++なので skencilがpythonだから推奨って感じか
799 :
デフォルトの名無しさん :2009/03/20(金) 19:57:21
799
800 :
デフォルトの名無しさん :2009/03/20(金) 19:58:33
800
inskapeってなんだよ
802 :
デフォルトの名無しさん :2009/03/26(木) 01:02:02
ふと気になりまして、 C++を普段使っている人は、STLやBoostをどれくらい利用しているのだろうか、と。 このスレにC++使いが居るのかわかりませんが、 1. 無いとやってられない。 2. 使うこともある。 3. そんなのあったっけ。 の中から選んでもらいたいと思います。 わたしは、C言語マンセーなので、C++の事情はあまりわかりません。 しかし、仮りにSTLやBoostをC++使いが、よく利用するのであれば、 C言語にもこれ以上のライブラリを作れば、C++が消えると思いましたので、 質問しました。
俺は1かな。でも標準に入りきってないboostはまだ未着手だな。 主にVectorでメモリの管理役をやってもらってる。 自作すると劣化版ができちゃったので妥協した。
Boost.PreprocessorはCでも使えるヨ
おれも1だな。 boostも1/3くらいの機能はもはや必須。
STLやboostと同等以上のライブラリのC版ができたとしても、Cには戻りたくないけどな。 namespaceやオーバーロード・ライド無しとか苦行だ
807 :
デフォルトの名無しさん :2009/03/26(木) 18:09:30
くさかべが2CHにやってきてム板を廃墟にしてくれないかな?
>>807 昔スレたってたと思うけど。VOIDの人。
ライブラリは使うだけで決して作らない クラスメンバーは全部public と割り切ってしまえばC++も便利だよね オブジェクト指向が効率悪いと気付くのに8年かかったよ
気の利いた抜け穴が大好きな人にはC++は向いてないと思うよ。
>>807 むかしトレイニングとか言ってnntp経由で書き込んでたことがあったね。
あの時は廃墟どころか祭りになってたけど。
俺はその時に高速に即レスを返すために初めて2ちゃんねる専ブラを使い始めたよ。
雪駄を全てoperator =で書けば便利になることに気が付いたぞ ただ、ライブラリを作るのが面倒くさくなったけどな
何が悪夢ってオペレータのオーバライドほどの悪夢はないな。
オーバーライド専用の予約オペレータがあると良さそうなんだがなぁ
簡単にパーサーがつくれるくらいシンプルな言語のほうがいい。 自動解析とかしにくいよ。
LinusっていちおうC++チェックしてたのか
>>815 C#なんて、IntelliSenseしやすいように構文設計してるからね。
>>812 誰もが一回は考えると思うが、型が同じものを複数指定できないから、やめてしまう。可読性も悪いし。
>>818 型が同じなら変えればいい
クラスを作るなり、構造体を使うなり、方法はいくらでもある
言ってるだろ、「ライブラリを作るのが面倒くさくなったけど」ってさ
よく分からんけど3. 組み込みやそれに近いものをC++でやるくらいなら Cかアセンブラでメモリ動作に集中して作るほうが結果的に早いと思う。 もっと大きなプロジェクトならC++じゃなくてJava使うし。 C++はWindowsデスクトップ用、特にQTとかDirectXとかに使う言語と思う。 それ以外に使い道が・・・十分すぎるほど十分だけど。 後はGPGPUに期待だな。
コピペで使うための俺ライブラリを作ってるからBOOSTとかいらね。 STLは標準だから使ってるけど。
Boostの変態共には一生かかっても勝てる気がしないから それらの劣化コピーでしかない俺ライブラリなんて作る気にはなれんです
劣化であっても俺ライブラリの方が大抵コンパイル速度で勝るから 意味はあるんだけどなぁ。
824 :
デフォルトの名無しさん :2009/03/28(土) 14:11:49
コンパイル速度で勝てるwwww
C++使いで俺ライブラリ使ってるぜと豪語する奴って 大抵木を見て森を見ずでどうでも良いところに凝る 印象。言語がそうさせるんだろうか
>>825 既存のライブラリが複雑で俺の頭では覚えきれないからです。
コンパイル速度は実務で意外に重要だから困る
boost 使っても理解してもらえない・・・
俺はC++はクソだと思う。 昔、超高速で有名だったとあるソフトを開発したのは俺。 今では誰も使ってない。 そんな俺がC++はクソだというのだからクソに決まってる。
C++は条件次第で大きく評価かわるかな。 STL+Boost+Qt ぐらいそろって始めて 高速・効率・可搬性の高さにメリットがでてくる。 そうじゃないならC、C#、Javaあたりのメリットにはかてないし。
Javascript+HTML位簡単にGUIアプリが作れればいいんだけどねぇ。ネーティブでさ。
832 :
デフォルトの名無しさん :2009/03/28(土) 17:50:57
ぽえりな臭がぷんぷんする。
いや、普通に速度求められるソフトじゃC++くらいしか選択肢ないから。
いいえCかfortranまたはアセンブリ言語です
winnyはDelphiだったよな
winnyはBCC
Winnyは最初Delphiで、バージョン2からBCB。 逮捕された時、押収品の中にちゃんとBCBのパッケージがあったw
Delじゃねーよ V1はVC++でV2からBCB
主要なソフトが何でできているかっていうリストはないんかね?
洒落はDelphiだな しかし洒落にならん 洒落を長時間起動させると音が出なくなる DirectSoundに悪さでもするんだろうか
それはplug-inに仕込まれているんだよ。 さっさと違法なソフトウェア(音声、映像、文章、アプリケーションなど)を共有または取得、配信するのはやめろ。 それでも自分の権利を主張できるプログラマか、見ていて恥ずかしいよ。 そろそろみんな話を元に戻そうな。
他人の権利は認めないが俺の権利は主張します。
C++を流行らせたのはWindowsだからなぁ
Linuxって体系がごちゃついているのとlinus個人の権限が大きすぎるのが嫌だ。 最初から最後までlinusがプロデュースしているならともかく いろんな人が絡んだ後でも絶対的権限を維持している感じが汚い。 だったらすっきりとプロダクションメイドのMacのがまし(Winもそうだがunix系ではないので) という事で選択肢にはない。
とりとめのない長文ですまん。 最初にいわゆるオブジェクト指向言語に触れたのは、Smalltalk だった。 おそらく、1980年代後半。 そのときの感想は、 「型(クラス)とサブルーチン(メソッド)がスゲエたくさん作ることになる。 それを管理できる開発環境込みじゃないととても使えん。」という感じ。 C++ に最初に出会ったときもそんなイメージだった。 そのころ、自分の仕事の開発環境は、UNIX(SunOS)上で C と emacs と gdb という感じでだったので、 その後 C++ を使おうとしたことがあったが、やはり、ライブラリを構築していくに従って、 管理が大変になり、「使ってられん。Smalltalk みたく、 開発環境がクラスライブラリを認識してくれないとかったるくてしょうがない。」と思って投げてしまった。 しかし、その後、SunOS(Solaris) 上でも GUIアプリの開発の必要がでてきて、 XView のライブラリとか触ったら(もちろん、Cベース) xv_set(object, attrs) ・・・ みたいな、「オブジェクト指向で書きたいんだけど Cだから仕方なくこうしました」 としか言いようのない API ばかりになっていて、「GUI は オブジェクト指向でやったほうが楽だ。」と感じた。 長らく Windows の主力開発言語が C++ だったのはそういう事情もあるんだろう。 Windows(MS-DOS)の世界では、TuboPascal からこっち、IDE の存在は当たり前になっていたから、 仕事でつかう UNIX では Cオンリーだった自分も、家では TurboC++ で遊んでいた。 しかし、ライブラリ化を巡る使いにくさというのはやはりあって、フレンドとかを無節操に使うとどうにもならなくなった。 Java がフレンドや多重継承をばっさり気って捨てたのは賢い選択だと思う。
その代わりへんてこりんなデフォルトスコープやらインターフェイスを採用してしまって、 いまその後始末で大変なことになってるんでそ
>>845 > 「GUI は オブジェクト指向でやったほうが楽だ。」
そうだよなぁ。結局適材適所で、
GUI系プログラマ「Cプログラマはウンコ」
んで、オブジェクト指向重視なら
Javaプログラマ「C++プログラマはウンコ」
C++は未熟な言語だけど、叩き台として優秀だったと思う。
>>846 JavaもScalaの叩き台になったよな
>>845 GUIというか、widgetはオブジェクト指向に合ってるよね
各コンポネントが基本的に独立してるし、ベースパーツを
継承して高機能なコンポネントを作ったり、とか
ただ考え方が統一されていれば、xv_set(object, attrs)でも object->set(attrs)でも
object set: attrs でもたいした違いじゃないように思う
>>849 別にオブジェクト指向が最適というわけでもないぞ。
erlangのようなプロセス代数モデルのほうがオブジェクト指向よりGUIに向いている。
関数型言語でのGUIの設計といえばFRPというのもあるな あとはmodel viewの分離を宣言的に定義できるtangible valueとか
またyampaか。 しかし、あれはGUIのモデルというわけではなくて、たとえば関数型言語でタイミング取ったりするような プログラムを書きたい場合のテクニックに過ぎないと思うけどね。 おまけに俺が論文を読んでyampaを使おうと思っても早速使えなかった。 やり方を理解するのに3日ぐらいかかったぞ。 俺の頭が悪いんじゃなくて、理解しにくいということだ。
Linusは情報工学とそこから出てきたものが大嫌いなんでしょ 能書きたれるばっかりで他人がまともに使えるものを何一つ作らないから
C++は確かにカオスだが、
バージョン1の頃のLinuxカーネルよりはまし。
>>844 Linusはプログラマとしては二流で、
むしろプロジェクトマネージャとして極めて優れている。
そういやPaul Grahamもエッセイで情報工学(笑)とか叩いてたな やっぱり使えるもの出さなきゃ認められんよな でもJavaとかPHPみたいに使えるもの出しててるものでも叩かれるよな
LinusもPaulも情報工学そのものバカにしているわけではないだろ はてなによく居るXXXは計算機科学的にクソだからクソとか知ったふうな口を聞く奴等は見ていて痛い
まあLinusはヘルシンキ大学で計算機科学を学び、 工学修士持ってるわけだが。 Paul Grahamだってハーバードで計算機科学、工学博士だし。 大学で学ばずにまともな物作っている人の方が珍しい。
大学で学んでもろくなもん作れない奴ってなんなの?
disってる暇があればろくな物つくれってか Linusとかはまともな物を作っていてその隙にdisるから許される…と なかなか建設的な論理じゃないか
まぁ、いろんな人がいるわな
俺が1時間以内に理解できない概念はクソだから流行らない これは明らか
>disってる暇があればろくな物つくれ 感情的にはそうなんだが、発言者の人格、性格で 発言内容の真偽が変わるわけではないからなぁ。
プログラミングすらできないのに情報系いくやつってバカだろ? 高校で数学さっぱり分からなかったけど大学の数学はなんかカッコいいし 金融機関に就職もバッチリだから数学科にしました、ぐらいに意味不明
学歴厨ぜえよ
>>849 そういう意味では、問題になるのはマニュアルかもしれない。
xv_set() のマニュアルページなんて、具体的な情報はほとんど無いに等しい(書きようがないし)。
Window.setWidth() とかになってれば、書くことはっきりしてるし、というか書かないでも分かる。
学歴が見られたもんじゃないやつほど学歴の話題に敏感
>>861 おいおい自分の頭が糞悪い事を棚に上げてよく言うよ・・・・
まぁカメラみたいなもんで、プロ仕様のよりもバカでも使える方が普及するだろうし。
>>861 流行している概念は誰かに租借や意訳されていろんな見解が出てくるから、万人向けになっている。
ゆえに、あんたがアーリーマジョリティ辺りなのは明らか。
870 :
デフォルトの名無しさん :2009/03/29(日) 16:27:59
他に代えようのないよほど優れたものでなければ、理解に時間がかかるものは普及しないよ。
それはオカシイて話。
873 :
デフォルトの名無しさん :2009/03/29(日) 16:38:55
C++なんかよりHaskellのほうが理解するのに時間かかったなあ。 C++なんて、いっても単純な規則が何層にも折り重なってるだけで 仕様を理解するのに時間は必要でも大して頭は使わない。 Haskellは基本的な概念から記号法から入り組みすぎてて 仕様の情報量はC++以下なのに理解するのにはC++の何倍も素養を問われる。
>>872 そのアーリーマジョリティーに受け入れられないものが流行らない
と言うことのどこがオカシイのか、全く意味不明
一騎当?ですか。
>>869 はアーリーマジョリティーって言いたかっただけだから。騒がせてごめんな。
俺なんか未だにPrologの文法がさっぱりわからないが C++はだいたいわかって使いこなせる どう見てもPrologの方が文法簡単だろ
>>878 何でさっぱり分からないものを簡単だと言い切ってるの?アホなの?
何とか辺りって書くと過剰反応する人いるよね。辺り!って節に。 意味的にはイノベータではないので!って意味なんだけど。読めなかったのか。/(^。^)\
これがC++脳ってやつか
>>873 君がC++でもHaskellでもサンプル程度の規模の
プログラムしか書いたことがない、というのは伝わった。
883 :
デフォルトの名無しさん :2009/03/29(日) 17:07:09
出来ることが同じなら、ルールが少ない方が本質的だからね。
>>882 いや、思いっきりGUIアプリ書いてるんだが…
GUIアプリ(笑)
どうした?なんか悔しかったのか?
887 :
デフォルトの名無しさん :2009/03/29(日) 19:35:54
>>884 、Haskellで書いた簡単なGUIアプリ見せてよ
Haskellでみんな何のGUIライブラリ使ってるの? gtk2hsとかっておもいっきりCでgtk使ってるのと変わらない印象を受けるんだが。
haskell使ってる人はGUIとかあんまり興味ないと思うんだよねぇ。
890 :
デフォルトの名無しさん :2009/03/29(日) 22:23:39
思うのは自由だ。
関数型が理解できる俺って頭いい。って言いたいんだろ。
つか、IDほしいよな、この板
>>891 > 関数型が理解できる俺って頭いい。って言いたいんだろ。
俺の人生経験上、そういう発言をするやつほど、
自分が思っていることを他人も思っていると勘違いする傾向にあるように思うよ。
つまり、
>>891 は「関数型言語が理解できるやつは頭がいい」と思っていることになる。
>>891 が関数型言語を理解している人間なら、ナルシストだということ判断できるし、
理解していないならただの嫉妬深い惨めなやつということだ。
要はあれだよ、自分の気に言わない発言してる人を見つけると、 そいつが「痛い理由」「馬鹿な根拠」でそれを言ってることにしたくてたまらなくなるタイプ。 「自分以外はみんな馬鹿症候群」の人が、具体的な言い返し方を思いつけない時に見せる、 キャラクターメイキングによる自尊心の維持ですね。
関数型っていうか、数学をさくさく理解できるレベルなら、 プログラミング言語まわりで苦労することはないんだろうな・・ 最近応用数学まわりの知識が必要になったんだけど、ぜんぜん理解できなくてきつい><
>>891 もうなんというか、哀れすぎて掛ける言葉が見つからんわw
>>898 関数型言語ができて、そしてGUIが出来るのが凄いプログラマで
応用数学が出来るのが凄いプログラマじゃないぽ
>>898 プログラミング言語の理解に数学の知識なんてほとんどいらないだろ。せいぜいブール代数くらいか?
プログラミングには数学の知識が必要になることもあるだろうけど。
>>900 数学が出来なきゃアルゴリズムのアイデアも浮かばないわけで・・
優れたプログラマ=優れた計算機科学者なわけです
>>902 数学を崇拝しすぎだろ。数学なんて単なる道具の一つだ。
よほどのパープリンじゃなければ、高校程度の数学ができればプログラムは書くには十分すぎる。
プログラマ=優れた計算機科学者 信じているって、数学科卒の人
根本的な間違いを指摘すると、計算機科学は数学科じゃない。
>>905 >>902 の
>数学が出来なきゃアルゴリズムのアイデアも浮かばないわけで・・
と
>優れたプログラマ=優れた計算機科学者
と関連を教えてクレ
>>898 理解できないものを必要と決め付けるのはおかしい。
数学をできれば、プログラミング言語が理解できるって、凄い幻想だよな。
でも、 国語が出来ればプログラミング言語が理解できるってのは正しい
自然言語プログラミングか。夢の世界だな。
設計やアルゴリズムを考えてプログラミングするのがプログラマで、 面白みのないありふれたコードを打つのがコーダ 誰でも知ってるようなアルゴリズムをライブラリから引っ張り出してコードを打つだけならそれはコーダの仕事であって、 より優れたアルゴリズムを発明して実装するのはプログラマの仕事。 最近のアルゴリズムはどんどん複雑化しているから、普通の人の頭にポンと浮かぶようなものではない。 常にアルゴリズムは数学的(計算機科学的)な体系を元に作られるものだ。
>>912 そう言う意味なら、アルゴリズムを作るのは計算機科学者。プログラマーはプログラムを作る人。コーダーはプログラムを打ち込む人。
御託を並べる前に、社会勉強してこい。
数学理解できないレベルでもプログラミングはできるってことを主張してなにが楽しいんだ?
プログラミング程度の作業に数学が必要なんて主張してなにが楽しいんだ?
>>915 お前さんの言う「数学」とは、どの分野のどのレベルのことを言うんだ?
昔CAD作ってたけど、そのときは数学必須だった。 高校の数学の参考書と、大学の幾何系の教科書はそろえた。 (特殊な例だとは思うが)
職業に科学者って付くと凄く聞こえるな ITドカタとは異なる世界の人だな マに科学者なんていないだろ
そりゃ文章書きだって、 社内のお知らせ文書書くレベルから、 法律書く人、哲学書書く人、小説書く人など千差万別だからね。 プログラム書く人だって、ピンキリだわね。
会計ソフトを作るのに会計の知識が必要だった。 競馬予想ソフトを作るのに競馬の知識が必要だった。 特定分野のソフトを作るにはその分野の知識が少なからず必要になる。 数学も単に特定分野の一つ。プログラミングにとって特別なものじゃない。
プログラマはいろんな分野の知識をつけられる素晴らしい職業ってことか。
いろんな分野のソフトを開発すればな
>>917 、
>>915 じゃないが
俺的には足し算引き算レベル
凄いだろ
普通は物理の素粒子論ぐらいに出てくるレベルの高等数学だろ
大学卒当たり前の今じゃ、教養レベルの数学は知ってて当然だろうからな
Webプログラマだったら誰でもなれるけど、 科学技術計算とかシミュレーションとかのプログラマだと人を選ぶよな。
>>914 あのね、ニートの君に言っておくけど、社会に出たらコーダーの事をプログラマーって呼ぶんだよ。
コーダーなんて仕事はないんだよ。
プログラマーが数学に憧れを抱いていることはわかった。
数学が、、数学さえできれば、俺はもっと凄くなれるんだー!! みたいなww
でも数学できるからといってHaskellがバリバリ使えるようにはならんよ。 たぶん数学全く知らなくてもHaskellバリバリ使うことはできるだろう。 例えば関係ないけど数学全く知らなくてもYコンビネータ導出できるだろ? ラムダ計算の理解があって導出方法を知っていれば。
Haskellに関しては、変な先入観が多すぎるなからなあ 高度な抽象化はもちろん低レベルな処理もしっかりこなせるのに、誤解されすぎ
Modern C++ design をパラ読みして、C++ すげーって思った。 それと同時に、C++ は使い手を選びすぎる言語だとも思った。 使いこなせる人だけ集まって使うのなら、かなりいいだろーな っていう印象。
皆さん日本語がお上手ですね。
なんかコンプレックスの塊のような奴らばっかだな
>>930 ラムダ計算の理解にだって立派な数学的素養が必要だと思うぜ
抽象化された世界で物事を考え進めていける力が要る
数学ができることと数学的素養があることは同値ではないがな
プログラミングには料理を作る程度の数学の素養が必要
9年前から会話の内容が変わってなくて安心した いつの時代もプログラムができる人間にコンプレックスを抱いてる人間がいるんだなあ
もう算数でいいよ
例えば私程度のプログラマだと、画像拡大時にリニア補間することくらいは簡単に思いつくし実装できるけど、 3次式補間辺りを境に、多次式の補間はちょっと手に負えない。 ソートにしても、クイックソートからイントロソートは想像できても櫛ソートなんかは想像できなかった。 大体その辺りが数学的素養の有無の境界線じゃないの?
計算機科学またはそれよりの数学科の博士課程を出ている人間とそれ以外
ド・モルガンの法則(笑)
ドモリ・マンの法則
>>936 9年ごときで「いつの時代も」なんて言ってんなよ
弩・モリマン
アルゴリズムは歯車のひとつにしかならない システム全体のデザインを考えるほうが楽しい
fractal
ところが小物ソフトは、たいてい一つの処理をするために使い勝手を良くするためのGUIとかがゴチャゴチャ付属している だけというものがよくある。 商用ソフトでもエンコとかは完全にアルゴリズムを売りにしてるだろ? 最近のgoogleの検索システムはクラウドコンピューティング(笑)だとか何とか言われてるけど、 そのネットワークを考えるにもパイ計算っていう数学を元に設計されてるの知ってる? パイ計算は関数型言語と親和性が高いから、今後googleも関数型言語一色に染まりそうだな。
小規模な業務システムには数学はいらないかもしれない。 そんな頭を使わなくて良いシステムのプログラミングは誰でも出来るから、 そんな仕事してるぐらいでプログラマ面されても困るw
金貰っていればプログラマ、コードを日常的に書いてればプログラマ ソースコードのあパラメータを少し変えてコンパイルして動作したときにSEGVるのもハックだし、 それをやる人もハッカー
>>946 GUI付属するのやめてたとえばDLLを使ってもらう形にしたら
本当にただの歯車になっちゃうよ
つか、そのほうが使い勝手良いんだけど
リーナス、ダイクストラ、チューリング、ストールマン、シャノン、ケント・ベック、アラン・ケイ、ウィル・ライト、チャーチ 彼らの秀でた能力すべてを数学的能力というならもれもそれが欲しいね。
リーナス = プロマネ ダイクストラ = 数学者 チューリング = 数学者 ストールマン = 宗教家 シャノン = 数学者 ケント・ベック = ほら吹き・しったか アラン・ケイ = ペテン師・しったか ウィル・ライト = 誰・・・?w チャーチ = 数学者
所詮そのレベル
ウィル・ライトはシムシティの人かな
大学の教科書に名前載ってる人の理論を知ったかしたいと。
以下本を読む論争
チューリング = アッー!!
958 :
デフォルトの名無しさん :2009/03/30(月) 21:33:33
数学数学言ってるバカがいるようだが プログラマーなら先ずお前の給与明細見てみろ。 特別な技能なんて必要とされてないことがわかるはずだ。 わからなければ、数学以前に数字を読めるようになった方がいい。
>>958 そんな底辺プログラマーの話はしてないんですよ^^;
960 :
デフォルトの名無しさん :2009/03/30(月) 21:45:41
プログラマーなのに底辺じゃないと思ってるなんておめでたいなw もう数学でも何でも好きにしていいよwww
プログラムに使う数学なんて底辺数学だろw 現代の数学者が現在取り組んでるようなものじゃない。
プログラマーの数学コンプレックスはすごいな。
963 :
デフォルトの名無しさん :2009/03/30(月) 21:52:31
数学を語るプログラマーって 英語で自己実現を夢見るOLと同じ精神構造だよね
違うよ、数学科崩れの出来ないプログラマーが幻想のアイデンティティを語ってるだけ。
>>960 おまえ・・みんながお前と同じ境遇だと思ってるのか?w
おまいら(´;ω;`) 弱い者たちが夕暮れ〜更に弱い者をたたく〜♪
日本ってハード信仰強すぎだよなw 何あのアホみたいな見積もり。 どんだけプログラマー馬鹿にしてるのよ。 と、趣味グラマーが仕事で見かけた扱いの悪さに怒ってみました。
悔しかったらハード作ってみればww
趣味グラマーってw ニートだろ どうせ
いや、コンパイラをインストールしてプログラムした気になってる中学生だろww
どんだけひとを低く見れば気が済むんだ。 おまえら「おれはバグを出さない。」って本気で思い込むタイプだろ。
973 :
デフォルトの名無しさん :2009/03/30(月) 23:14:48
バカな人を低く見るのと、自分を過信するのとは違う
違うけど近いな
どっちみち嫌な奴にはかわりない。
昔コーディングするのは理系と相場が決まっていたが 今や文系のほうが多いみたいだからな Knuth先生が言っていたのと全く違う意味で
いや、昔はA型が多くて今はO型が多いみたいだよ
劣性遺伝のO型が増えるというのが不思議だ
遂に血液型談義にまで発展したか どうしようもないなw
初心者なんですが、 A型(アセンブリ)、O型(オブジェクト指向)で合ってますか? わかりません><
A型はアスペクト指向ですよ。
C++は不格好な言語だからな。 ネイティブバイナリ吐くメジャーなOO言語が何でないんだ。 D言語とかどっかIBMとかでいいから買い取れよ。
UNIXはマウントして使うものだから 常時ハードウェアの状態を監視したりしてないんじゃないの?
何の話?
過去の資産の互換性をばっさり捨てればc++も綺麗になるんでない?
C++を捨てるほうが早い
組み込みでは大成功だね 機能を絞って使えば。 機能を絞って使えば。
Linus,C++出来ないの?
990 :
デフォルトの名無しさん :2009/04/01(水) 00:25:18
出来ると思ってるお前よりは出来るが本人はそれを「出来ない」と思っている。
まぁboost見た後だと9割くらいのC++使いは自分の未熟さを思い知るんじゃないか。
boostはともかくパズル解けるほうがすごいと思ってる奴が多い。
bindやfunctionのクラスなんてわけわかめ
lambdaとかC++じゃなくてテンプレートを使ったlispもどきだからな gccのプリプロセッサを使ったlispもどきといい勝負してるよ悪い意味で
lispの影響を受けるのは仕方ないだろ? 日本の戦後もアメリカの影響を受けてここまで成長したんだ。
>>994 関数がファーストクラスオブジェクトでない言語でやると
こんなに汚くなりますって見本だな, boost lambda
boostは涙ぐましい努力で無理矢理実現してるから汚いのも仕方ないが 言語仕様として追加されたC++0xのlambdaも同じくらい汚いってどういう事なんだろ
作ってる人が同じだから。。。
C++は、使う人によってどうしようもなく変態な言語になる。 非効率で廃れやすくて保守が難しくなって自然消滅するプロジェクトにはもってこいの言語ということでFA。 私は、C言語で十分満足しているから、C++は使いたくないね。
>>999 で、何故お前はどうしようもなく変態なコードをCで書いてしまうんだ?
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。