09/02/11 15:43:09
> Git のソースコードを最初に見たとき、ヘンだと思ったこと:
> 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性が
> どうとか言わないで、
> そんなのウソに決まってるから。
*あんた* のほうこそ大ウソつきだ。
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが
使ってるためにさらに輪をかけてゲロゲロになっていて、どうし
ようもないゴミが簡単に生産されるようになってる。正直いって、
C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だっ
たとしても、それ自体、C を使う強力な理由になりうる。
Linus Torvalds
URLﾘﾝｸ(tabesugi.net)
前スレ
Linus「C++プログラマはウンコ。寄ってくるな」
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
09/02/11 15:46:07
これは支持する。
3:デフォルトの名無しさん
09/02/11 15:50:37
パート２はマ板に立て直すかと思ってた。
4:デフォルトの名無しさん
09/02/11 15:54:25
.llllll
: ,,,,,,,,,,,,,,,,,,llllll,,,,,,,,,,,,,,,,,,
: llllll!!!!!!!!!!!!!!!!!!!!!!lllllll
: llllll llllll
: l!!!! ,illlll′ ,,.llllll,、 . .llllll,,,,
,,illllll゜ ﾞ lllllli、 . llllll!
,,,illlll!ﾞ , ﾞ!!!!" ,,llllllﾞ
,,,,iilllll!!ﾞ ｳｪｰﾊﾊﾊ♪ , ,lllll!°
-､_ llllllll!!ﾞﾞ゜∧＿∧ ｼｭｰ｡:*ﾟ ,,illlll!ﾞ｀
`‐-､_ < ｀∀> f ｡:*ﾟ｡ ・｡*:illlll!ﾞ°
`-,ﾉ ,つ[_]; llilllll!!ﾞﾞ｀
（〇 〈-`'"
(＿,ゝ ） `‐-､_
（＿_フ `'‐-､,_..
`‐-､
5:デフォルトの名無しさん
09/02/11 17:48:32
リーナスなんてウンコ臭くて誰も近寄らねぇよってんだよ
6:デフォルトの名無しさん
09/02/11 19:19:48
２スレ目なんていらねえだろw
7:デフォルトの名無しさん
09/02/11 23:43:03
>>3
そこまでの知能が >>1 にあれば
そもそも2ｽﾚ目なんか勃てないだろう。
8:デフォルトの名無しさん
09/02/12 00:01:15
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
9:デフォルトの名無しさん
09/02/12 00:10:08
2糞目
10:デフォルトの名無しさん
09/02/12 22:33:35
∧∧
～′￣￣(,,ﾟДﾟ)
UU￣U U
11:デフォルトの名無しさん
09/02/13 06:35:46
＿ ,､_,､ ,
ﾞフ ﾞ) 'д')__ノ,ﾐi 1ｻｰﾝ ﾊｧﾊｧ
i彡'^ヽ. i―'゛
〉 `--､ ,,,,,,,,,
/ ／￣ﾌ/ ( 'д)_ ｳﾜｰﾝ､ｷﾓｲﾖｰ
,ノ／ ﾚ' ﾉ 1. r'
ﾚ' ﾞ-'｀ｰ'
12:デフォルトの名無しさん
09/02/13 08:04:43
>>1の説得力に脱帽
13:デフォルトの名無しさん
09/02/14 12:09:27
平均以下ってところがポイントだな
14:デフォルトの名無しさん
09/02/14 14:14:56
class C++Programmer : CProgrammer
{
Productivity OOP();
}
15:デフォルトの名無しさん
09/02/14 15:16:48
こいつマイクロカーネルの悪口も言ってただろ。
単なる老害
16:デフォルトの名無しさん
09/02/14 15:56:54
マイクロカーネル（笑）
17:名無しさん
09/02/14 18:31:42
A Real Programmer Can Write in Any Language (C, Java, Lisp, Ada)
URLﾘﾝｸ(www.stsc.hill.af.mil)
とか
Learn how to program.
URLﾘﾝｸ(www.catb.org)
とか
18:デフォルトの名無しさん
09/02/14 19:09:18
立場的にC言語でも困らないレベルの連中とだけしか仕事してないからそうなるんだろうな。
底辺にいくと、自分の技量がある段階を超えたらC++を使った方がやりやすくなるよ。
ザコ用にいろいろ準備したり制限かけたりできるし。
19:デフォルトの名無しさん
09/02/14 22:34:59
C++でないと出来ない準備とか制限って何？
インタフェースと実装を分ける、というような話なら
Cでもプロトタイプ宣言で出来るし、コーディングスタイルに
関することならCでもC++でも出来ないだろうし
20:デフォルトの名無しさん
09/02/15 00:31:44
型の扱いが厳しければCのほうがマシってケースは多々ありそうだけど
クラスが無い、型に厳しい、なら関数型言語使うよ
組み込みの人達はそうはいかないんだろうけど
21:デフォルトの名無しさん
09/02/15 00:36:13
組み込みといっても、Objective CとかJava使えるんだから関数型言語もありかもしれん
22:デフォルトの名無しさん
09/02/15 00:38:41
>>18
という妄想を見てるんだろうね
23:デフォルトの名無しさん
09/02/15 00:40:12
>>21
その組み込みって携帯電話のこと？
24:デフォルトの名無しさん
09/02/15 00:41:55
templatemethodとかが適用できるような案件だったら、
「作るべきコード」が強制できる罠。
逆に無理してこうしたパターンに当てはめようとしちゃう所がダメなのかもね。
25:24
09/02/15 00:46:27
でも「クラスが分からない」レベルで足切りしたいなら有効かもね。
Cだと上下に幅があり過ぎる上に、スキルを測る上での指標が少ない…
26:デフォルトの名無しさん
09/02/15 01:03:49
クラスのメンバ関数をprivateにできるだけで十分制限になるだろ。
27:デフォルトの名無しさん
09/02/15 01:08:54
外で自由自在に魔法コードかかれるよ
28:デフォルトの名無しさん
09/02/15 01:20:12
特定クラスしか受付しない機能をライブラリ化して渡せばそんな程度じゃ困らんぜ。
29:デフォルトの名無しさん
09/02/15 01:24:04
#define private public
30:デフォルトの名無しさん
09/02/15 01:26:07
デフォルトでローカル変数がconst扱いになるだけで
C++はマシになると思う
31:デフォルトの名無しさん
09/02/15 01:26:42
変更したかったら mutable か
32:デフォルトの名無しさん
09/02/15 01:27:34
>>30
0xでそれをしないのは本当に馬鹿だと思った。
33:デフォルトの名無しさん
09/02/15 01:34:19
互換性なくなるだろそんな変更ｗ
34:デフォルトの名無しさん
09/02/15 01:53:21
ローカル変数なんてほとんど害ないと思うんだが。
そんな長い関数でも書いてるの？
35:デフォルトの名無しさん
09/02/15 01:55:01
良く使うものに限ってconst、constと名前が長くなるのは美しくない
36:デフォルトの名無しさん
09/02/15 01:55:50
むしろデフォルトでclassをsealedにしろ
std::stringを継承するアホがいたので
37:デフォルトの名無しさん
09/02/15 02:15:32
>>34
"どれも変更されるかもしれません"
"これとこれは変更されるかもしれません"
どっちのがわかりやすい？
38:デフォルトの名無しさん
09/02/15 02:21:26
>>37
いやローカル変数なんて範囲狭く出来るだろ。
問題としては大きくない。
グローバル変数や大量のメンバ変数もつクラスのほうが問題が大きい。
39:デフォルトの名無しさん
09/02/15 02:23:39
それは定数じゃね。
40:デフォルトの名無しさん
09/02/15 06:13:24
>>15
いや、AST教授の方が老人なワケだが。
Linusは経験不足な青二才。
>>19
馬鹿避け。大規模案件だと、チーム全員が君のようなスキルが有るとは
限らない。むしろ一番底辺のザコに皆が合わせないといけなくなる。
>>21
使えねーよ。 >>23さんの言う通り、携帯電話のしかも画面作りだけだろ。
組込みに限らず、デバドラとか書くのにjavaとか使えねー。オシロやICEと
睨めっこしながら、タイミング計算したプログラム書くならアセンブラか、
C(=高級アセンブラ)に限る。
41:デフォルトの名無しさん
09/02/15 10:01:13
>30-36
そもそもC++のダメな部分て、互換性に起因するモノが多い気もするな。
（特にCとの。）
42:デフォルトの名無しさん
09/02/15 11:36:09
ドライバ作りならPCだってそうだべ。
アプリ作る話だよ。
43:デフォルトの名無しさん
09/02/15 12:51:13
だから、それを「組み込み」と言うのかって話
44:デフォルトの名無しさん
09/02/15 12:52:36
>>38
範囲の問題にしてるのはお前だけだからww
45:デフォルトの名無しさん
09/02/15 12:55:42
スレを見る限りC++はウンコ
46:デフォルトの名無しさん
09/02/15 13:11:38
おまえらがウンコなことはよーくわかった。
スレタイも読めないんだからな。
いいか、ここは「C++がウンコ」のスレじゃないんだよ。
わかったらスレタイの話題に戻せ。
47:デフォルトの名無しさん
09/02/15 13:13:52
>>46
スレタイの内容について意見の統一ができたってだけだろ
48:デフォルトの名無しさん
09/02/15 13:17:47
うんこでちゃいますぅぅぅぅ！
49:デフォルトの名無しさん
09/02/15 13:21:12
自分がうんこプログラマであることは否定しない前提なんだけど
C++おもしろいよ。
あと、Cはプログラマはすべてわかっているっていう前提の言語だから
レベル低い人が使うとC++よりもひどいことに。
50:デフォルトの名無しさん
09/02/15 13:21:38
>>46
スレタイだけではなく、>>1の内容でスレの内容が決まる。
>>1には「C++ はひどい言語だ。」と書いてある。
つまり、ここは「C++がウンコ」のスレでもある。
51:デフォルトの名無しさん
09/02/15 14:07:34
C/C++どっちがひどいことになるって言ったらC++のほうがひどい。
52:デフォルトの名無しさん
09/02/15 14:17:27
俺がC/C++使うとCの方がひどいコードになるなぁ。
C++やると引数が5個以上の関数ってあんま作らなくなった。大体1個か2個。
53:デフォルトの名無しさん
09/02/15 15:16:12
それって大きなクラス作ってるだけだろ・・・
54:デフォルトの名無しさん
09/02/15 15:35:46
stringとvector使うだけでもバグは減るんじゃねｗ
55:デフォルトの名無しさん
09/02/15 15:46:45
>>53
正解！
>>54
アウトオブレンジ系のバグって凶悪なのに簡単にできちゃうから、vector使うだけでも大分違う。
あと、Vector使うとMallocしなくてよくなるからおかしなバグもおきにくい。（もちろん内部ではやってるの知ってるよ？）
56:デフォルトの名無しさん
09/02/15 16:04:03
そのカッコ痛いからやめた方がいいよ
57:デフォルトの名無しさん
09/02/15 16:06:34
でかいクラス平気で作ったり、確保領域の範囲外のアクセスを簡単にやっちゃうような
ヘボはC++かJAVAかVB(笑)あたりで遊んでてくだちい
58:デフォルトの名無しさん
09/02/15 16:19:46
クラスはメンバ変数3つ（静的1，動的2）、メンバ関数2つ（なんとかラクタとgetter/setterは仕方ないから除く）
までが許容範囲
59:デフォルトの名無しさん
09/02/15 17:00:23
さすがにそれじゃ今度はクラスが大量に出来るだけ。
60:デフォルトの名無しさん
09/02/15 17:56:16
Cのがベターって奴はお馬鹿さんへの啓蒙活動に疲れ切って、
とりあえず理想と現実の落差が小さな所に逃げてるだけって希ガス。
まぁLinusみたいに相手を選べない立場に居る香具師だったら
それもやむ無しだろうけど。
61:デフォルトの名無しさん
09/02/15 18:02:49
それは当たってる。
人数が多いだけの大型案件だと、情報系でないどころか
未経験の文系出身者が大量に流入して来るからな。
大学でもないのに、ワザワザ給料払ってまで教育してあげる
のには疲れ切った。
本来OOPって大規模開発のための技術だったハズ
なのに、現実の大規模案件ってオブジェクト指向
どころか構造化すら理解出来ない文系ウンコPGの
巣窟に成ってしまいがち。教育コストを考慮する
と、OOPって存在意義が無いわ。
62:デフォルトの名無しさん
09/02/15 18:06:02
C++は、OOPやらなきゃ初心者に優しい言語だよｗ
63:デフォルトの名無しさん
09/02/15 18:06:17
OOPが大規模案件向けってのは昔からあるデマだな。
64:デフォルトの名無しさん
09/02/15 18:06:32
>>59
小さいクラスを大量に作ることは何も悪くないぞ
少なくとも巨大クラスを1個作るよりは圧倒的にまし
65:デフォルトの名無しさん
09/02/15 18:54:37
「分割して統治せよ」っていうのは
スコットメイヤーズ先生もおっしゃっていた。
モノシリックなクラスを少数作るよりも
小さなクラスを大量に作るほうがいい。
さらにメンバ関数は極力減らして、非メンバ関数にするように、とも。
66:デフォルトの名無しさん
09/02/15 18:58:35
小さなクラスがただ大量にあるのはメンバ変数が大量にあるのとあまり大差ない。
67:デフォルトの名無しさん
09/02/15 19:01:51
っていうか、モノリシックであった。ひどいtypoをしてしまったと今は反省している。orz
68:デフォルトの名無しさん
09/02/15 19:03:29
前スレのdatくれ
69:デフォルトの名無しさん
09/02/15 19:04:00
デバッガで追うとすごいことになりそうｗ
70:デフォルトの名無しさん
09/02/15 19:37:06
>>55
なにこれ？
malloc使ってバグると凶悪で、vector使ってバグるとバグが分からなくなる？
C++プログラマはウンコだからプログラマやめろ。
71:デフォルトの名無しさん
09/02/15 19:42:06
>>70
凶悪なミスリードだな。
単純に2重開放がなくなったり、OutOfRangeを検出したり利点がある位の意味だけどなぁ。
72:デフォルトの名無しさん
09/02/15 19:46:30
検出できないだろハゲ
73:デフォルトの名無しさん
09/02/15 19:48:04
物理的には書き換えたかはわからないが、未然に防ぐことは可能だろう。
何のための例外とsizeメソッドなのかねぇ。
74:デフォルトの名無しさん
09/02/15 19:56:57
結局検出できない。
で、1バイト単位での移動チェックね、遅いわけだ。
75:デフォルトの名無しさん
09/02/15 20:00:13
物知りっくｗｗｗ
76:デフォルトの名無しさん
09/02/15 20:04:43
vectoの.at()を使えば、領域外参照で例外スローする。
77:デフォルトの名無しさん
09/02/15 20:08:33
>>74
やっぱ遅いって言い出したか。
vectorの場合、オペレータオーバーロードは関数呼び出しのオーバーヘッドが多少あるが、
その中でsize()以上であれば例外を呼ぶし、基本的に場所を補足するのはo(1)だ。
不等式知らないんですか。
あ、MSec以下のチューニングしないといけない人なんですね。
78:デフォルトの名無しさん
09/02/15 20:15:40
メガセカンド？
79:デフォルトの名無しさん
09/02/15 20:20:21
想定内だなぁ。ミリセカンドでしょ。
80:デフォルトの名無しさん
09/02/15 21:00:10
>>66
そんなことはない。
81:デフォルトの名無しさん
09/02/15 21:13:15
大差ないと同じは違いますよ？
82:デフォルトの名無しさん
09/02/15 21:19:44
アジャイルプラクティスではバランス感覚が重要だと言っていた。
つまり、（標準ライブラリのstringクラスのような）物知りっくな巨大クラスを設計してはいけないが
かといって有象無象のほとんど似たような機能がオーバーラップする小さなクラスをいくつもばら撒くのも間違いだ。
83:デフォルトの名無しさん
09/02/15 21:19:51
>>81
そんなことは知ってる。だからどうした。
84:デフォルトの名無しさん
09/02/15 21:33:01
現場を知らずに語っちゃうタイプ多すぎｗ
85:デフォルトの名無しさん
09/02/15 21:38:15
>>84
お前のこと？
86:デフォルトの名無しさん
09/02/15 22:41:13
C++使いの有名人をヲチしてみたいんだけど
誰かいませんかね
87:デフォルトの名無しさん
09/02/15 22:50:27
>>86
スコット・メイヤーズ
ハーブ・サッター
アンドレイ・アレキサンドレスク
88:デフォルトの名無しさん
09/02/15 22:56:25
>>86
FreeMLでML作ってるエー何とかっていう日本人がいるよ
89:デフォルトの名無しさん
09/02/15 23:11:01
>>87,88
サンクス
90:デフォルトの名無しさん
09/02/15 23:45:57
>>88
エピステーメー？
最近はC#に気持ちが行ってるようだが…
91:デフォルトの名無しさん
09/02/15 23:52:56
Cryoliteとかcpp_akiraとかはどう？
92:デフォルトの名無しさん
09/02/18 19:47:20
俺は、「プログラマは寄ってくるな」
って言いたいｗ
C++出来ますなんていってる人はイヤだ。
俺様ですらまともに扱えないもんを貴様が使えるわけなかろうて
93:デフォルトの名無しさん
09/02/18 20:09:36
私なら、「少なくともC言語とPerlとCommon Lispを使えないプログラマは、寄ってくるな」
って言いたい。
理由は、
C言語を使えると言うことは、ハードに近い部分も扱えるプログラマであるから。
Perlを使えると言うことは、スクリプトでできることはスクリプトで作ったり、プロトタイプをすぐに提出できたりするプログラマであるから。
まぁ、別にPythonでもRubyでも構わないけど。
Common Lispが使えると言うことは、関数型言語(Lispは、純粋な関数型言語ではないけどね)でもプログラムを考えることができるプログラマであるから。
C++は、中途半端なマルチパラダイム言語なのが好かない。PerlもRubyもだけど。
94:デフォルトの名無しさん
09/02/18 20:41:53
何故Common Lisp?
関数型というならSchemeか、いっそMLかHaskell。
95:デフォルトの名無しさん
09/02/18 20:43:57
>>93
あと TeX も
96:デフォルトの名無しさん
09/02/18 21:14:54
そしてC++。
97:デフォルトの名無しさん
09/02/18 21:44:45
しかしVerilog。
98:デフォルトの名無しさん
09/02/18 21:50:32
>>94
俺93じゃないけど、その中からどれか1つということでいいんじゃないかな。
自分はScheme使ったことあるが。
99:デフォルトの名無しさん
09/02/18 21:58:49
>>97 VHDL は却下ですか？
100:デフォルトの名無しさん
09/02/18 22:12:04
>>98
関数型言語がたくさんある中で、わざわざ
C++と同じ意味で「中途半端」なCommon Lispを選んでるのを見ると、
単に好き嫌いでいってるかんじゃないのかなあ。
101:デフォルトの名無しさん
09/02/18 22:34:30
寄ってくるな!とまでは思わないけどC派生型の言語しか使ったこと無い
新人には、毛色の変った言語の習得を勧めるな。
思考が限定されてしまうのは、実に勿体無いことだ。
102:デフォルトの名無しさん
09/02/18 22:34:33
達人プログラマーの続編に当たる（といわれる）アジャイルプラクティスでは
プロジェクトには最も適した技術（言語やフレームワークなど）を利用し、
どんな新しい技術にも投資し、古くて生産効率の落ちた技術は捨てろと書かれていた。
103:デフォルトの名無しさん
09/02/18 22:39:12
俺なら C と Scheme だなー。
C は >>93 と同じで、低レベルなプログラムが書けるってことで。
Scheme はスクリプト、関数プログラミング、マクロを使ったメタ
プログラミングってとこかな。
104:デフォルトの名無しさん
09/02/18 22:43:25
>>102
そして、投資し終わったころには、投資した技術は古くて生産効率の落ちた技術になっていると。
105:デフォルトの名無しさん
09/02/18 23:05:38
>>100
自分が使える言語をリストアップして悦に浸るやつは多そうだけどな。
106:デフォルトの名無しさん
09/02/18 23:07:48
だいたい、言語をあちこち並べる奴の何割が、*きちんと*Cを理解しているやら怪しいもんだ
感覚的に「Cできます」とほざく連中の９０％かそれ以上は言うほどわかってない
107:デフォルトの名無しさん
09/02/18 23:26:02
まぁ「Cを理解してない」と言うヤツの、かなりの割合が
自分がCを理解してないわけだが
108:デフォルトの名無しさん
09/02/18 23:30:03
・わかってなくても口を挟める
・明らかな嘘を言ってもばれてないような気がする
これは論点がどうでもいい所にずれてる兆候。
109:デフォルトの名無しさん
09/02/18 23:31:08
「Cができます」ってのはどのくらいのレベルがあれば言ってもOK？
110:デフォルトの名無しさん
09/02/18 23:33:27
面接官の女性がほほを赤らめたら勝ち
111:デフォルトの名無しさん
09/02/18 23:35:49
>>109
アセンブラと同じことができるようになった場合
ぶっちゃけ Uuix系 OS の kernel を何不自由なく読めるようになった場合
112:デフォルトの名無しさん
09/02/18 23:36:04
高級アセンブラの異名をとるくらいだから
コンパイラが吐き出すニーモニックが透けて見えるレベルなら問題ないんじゃないの？
結局、アセンブラ使って直接石叩いたりすんのがめんどーだから
Cとライブラリ使うんだろうし
とか適当なことを
113:デフォルトの名無しさん
09/02/18 23:37:21
>>109
グシケン、ヤマワキ程度
114:デフォルトの名無しさん
09/02/18 23:38:57
業務系のプログラマにはハードを直接叩くような要求絶対にないから
C言語使えなくてもいいよね！
115:デフォルトの名無しさん
09/02/18 23:40:49
いいよ。
116:デフォルトの名無しさん
09/02/18 23:41:38
>>114 COBOL, PL/I, PASCAL, Java, C++, … … …
お好きなものをどうぞ
「FORTRAN, LISP には手を出さないのが吉」だと思われる
117:デフォルトの名無しさん
09/02/18 23:51:55
>116
lispは業務系のPGでも、大量のデータ作ったりするのに使える。
emacs使いには特にお勧め。
そうじゃない人はPerlとかJavaScript、シェルスクリプトでも良いけどね。
118:デフォルトの名無しさん
09/02/18 23:53:10
Emacsは使ってるけど、そういうときにはRubyちゃん！
119:デフォルトの名無しさん
09/02/18 23:55:02
>>117
C も読み書きできない奴が Lisp をこなせるとは思えないんだが
120:デフォルトの名無しさん
09/02/19 00:20:08
>117
Cが分からなくてもExcelのワークシート関数でそこそこ複雑な処理をこなせる奴が居るんだから、
ちょっとしたデータの作成や集計位はできると思うけど。
まぁemacsを使う方が難しいかもしれないが…
121:デフォルトの名無しさん
09/02/19 00:32:40
>>119
CよりLISPの方が簡単なのだが。
122:デフォルトの名無しさん
09/02/19 00:45:58
>>121 それはうそ
native 吐き出すコンパイラ持ってる奴は C よりコンパイラの振る舞い
知っていないとまともな速度が出ません
123:デフォルトの名無しさん
09/02/19 00:47:18
構造体とクラスを明確に分けなかったこととは個人的に問題有りだ。
memcpyとか使って大丈夫なんだっけ？
構造体にデストラクタ仕込むとthisポインタが生成されるんだよね？
124:デフォルトの名無しさん
09/02/19 00:54:36
>>122
それは簡単かどうかとはあまり関係ないと思う。
125:デフォルトの名無しさん
09/02/19 00:56:02
>>123
クラスでも構造体でも条件を満たせばmemcpyできるし、仮想関数作ればvtableが作られる。
126:デフォルトの名無しさん
09/02/19 01:00:25
>>123
何を怖がっているの？
127:デフォルトの名無しさん
09/02/19 01:01:16
>>122
その前に助詞の使い方覚えようぜ
128:デフォルトの名無しさん
09/02/19 01:10:58
C++って経験浅い奴ほど自信満々だよね
129:デフォルトの名無しさん
09/02/19 01:11:59
例えば？
130:デフォルトの名無しさん
09/02/19 01:20:05
>>126
131:デフォルトの名無しさん
09/02/19 01:23:50
c++の親玉は音声認識の分野を追い出された人っぽいんだけど
単なる白い巨塔みたいな争いの延長臭い気がしないでもない
BSD vs Linux
の争いも似たようなもんだったよね．
linuxは綺麗じゃないけど，使う側にしてみたらドライバー揃ってるほうがいいから
結局linux使うっていう.
同じ意味での争いがpython vs lispでもみれたことあったな
library揃ってるpythonか綺麗にかけるlispかみたいな
132:デフォルトの名無しさん
09/02/19 02:05:09
C++は何か苦手だ。PERLと似たような苦手意識がある。
何でもできるは何にもできないのと同じ的な印象が強い。
ぶっちゃけプログラム言語は言語自体はシンプルなのが一番だ。
メモリレイアウトに集中するだけで組めるC言語とか、
意味論に集中できるJavaやC#といった言語が素敵に思える。
133:デフォルトの名無しさん
09/02/19 02:10:53
別に、C++が使いたいから使っているのではなく
そのプロジェクトではC++しか選択肢がないから使っているわけで。
結局、複数の言語をいやおうなく習得する羽目になる。
134:デフォルトの名無しさん
09/02/19 02:18:02
名前空間をサポートしたC言語が夢の言語って意見もあるしね。
135:デフォルトの名無しさん
09/02/19 03:52:59
いいなそれ
136:デフォルトの名無しさん
09/02/19 04:17:35
Obj-C+名前空間がいいな
137:デフォルトの名無しさん
09/02/19 14:01:59
(静的な)名前空間 -> 動的な名前空間 -> ADT -> オブジェクト指向 -> そしてC++へ。
138:デフォルトの名無しさん
09/02/19 21:17:43
ウンコから言わせてもらうとC言語とか云々以前にまずは母国語を（ｒｙ
139:デフォルトの名無しさん
09/02/19 21:39:58
いまどき日本語しゃべれるプログラマの方が少ないだろ！
半数は中国人、1/4は韓国人、残りが国籍不明
140:デフォルトの名無しさん
09/02/19 23:05:44
Effective C++等のルールに沿って禁忌事項を出来ないようにC++の文法を整理すると
C#の文法になります。
141:デフォルトの名無しさん
09/02/19 23:13:19
名前空間だけC++の機能を使えばいいんじゃね。
142:デフォルトの名無しさん
09/02/20 00:47:54
コンパイルエラーをサポートしたコンパイラがなければ意味がない
143:デフォルトの名無しさん
09/02/20 11:20:43
図書館でLinuxのカーネル関係の本借りてきて
まだ最初のほうしか読んでないんだけど、
読んでてふと思ったことがあった。
もしかしてOSを仮に作るとしたら（実際は作りませんが・・・）、
C言語の標準ライブラリ関数だけでは機能不足だから
インラインアセンブラ必須って理解でいいんですか？
144:デフォルトの名無しさん
09/02/20 11:28:59
お前はカーネルの本なんて読んでも無駄だから本はさっさと返せ
145:デフォルトの名無しさん
09/02/20 12:37:22
いやです。この本は今日から毎晩ほおずりして愛で倒し俺のにおいをつけまくることにしました。
146:デフォルトの名無しさん
09/02/20 13:16:32
いや、普通に読めよｗ
147:デフォルトの名無しさん
09/02/20 22:35:26
>>143
インラインアセンブラというより生のアセンブラ必須
148:デフォルトの名無しさん
09/02/20 23:21:41
>>143
一応言っておくけど、ＯＳの機能が無ければＣ言語の標準ライブラリはできないよ。
ＯＳが先で標準ライブラリは後。
で、ＯＳを作るにはインラインアセンブラは必要だろうね。
>>147
「生」が何なのか不明だけど、インラインアセンブラで十分だよ。
149:デフォルトの名無しさん
09/02/20 23:24:46
>>143
こんなところは, C は書けないんじゃね?
o initial boot 部分(多くの場合 BIOS とも呼ぶ)とか
o 割り込み/トラップエントリーとか
o c の start up とか
150:デフォルトの名無しさん
09/02/20 23:30:22
>>148 は >>149 をインラインアセンブラでどう書くつもりなのか
151:デフォルトの名無しさん
09/02/20 23:37:40
>>149
全部Cで書けるよ
というか特に理由が無いかぎりCで書く場合が多い
無理なところは最小限のインラインアセンブラを使うけど
152:デフォルトの名無しさん
09/02/20 23:39:19
>>149
> o initial boot 部分(多くの場合 BIOS とも呼ぶ)とか
BIOSはOSの部分ではない。
> o 割り込み/トラップエントリーとか
インラインアセンブラでかけるだろ。
> o c の start up とか
「c の start up」って何のこと？
153:デフォルトの名無しさん
09/02/20 23:47:56
どうしてもアセンブラが必要なところは、レジスタを直接書き換えなきゃ
いけない所だけ。割禁とかね。
それ以外は全部Cで書ける。効率的かどうかは別にして。
154:デフォルトの名無しさん
09/02/20 23:49:54
>>152
> o 割り込み/トラップエントリーとか
書けないね
特定のCPUに特化したコンパイラじゃなきゃ
> 「c の start up」って何のこと？
スタックポインタとか最低限のレジスタ設定しなくてcのアプリって実行できるのか?
155:デフォルトの名無しさん
09/02/20 23:50:18
レジスタを書き換える関数を作って呼べばいい。
それが駄目って言うなら、in/out や int なども C でできないことになる。
156:デフォルトの名無しさん
09/02/20 23:53:48
>>154
> 特定のCPUに特化したコンパイラじゃなきゃ
別に特化しなくてもいいだろ。そのCPUのコードが吐ければ。
> スタックポインタとか最低限のレジスタ設定しなくてcのアプリって実行できるのか?
それをするのはOS。OSのその機能はCで書ける。
ところで、何で「cの」なんだ？何で書いてもアプリはアプリだろ？
157:デフォルトの名無しさん
09/02/20 23:57:38
さすがにレジスタを直接イジるCの関数は無理だw
158:デフォルトの名無しさん
09/02/20 23:59:35
世の中には組み込み関数という便利なものがあってだな・・・
__emit__ 最強
159:デフォルトの名無しさん
09/02/21 00:00:10
>>158
それアセンブラだろ
160:デフォルトの名無しさん
09/02/21 00:02:09
>>157
インラインで書ける
161:デフォルトの名無しさん
09/02/21 00:04:36
スタックポインタを設定せずに C の関数が実行できるのか？
162:デフォルトの名無しさん
09/02/21 00:04:52
c だけで自分が作ったプログラムを boot strtap してみろよ
163:デフォルトの名無しさん
09/02/21 00:11:26
>>159
いいえ、マシン語を埋め込む[関数]です
164:デフォルトの名無しさん
09/02/21 00:11:45
OS上のアプリケーションしか組んだことが無い人は、ワンチップマイコンの
評価キットで遊んでみることを勧める
買っても1k円しないし、トラ技のオマケだったりするし
どういう風にブートしてるとか良くわかるよ
165:デフォルトの名無しさん
09/02/21 00:24:55
>>159が総叩きにあってないのが意外
166:デフォルトの名無しさん
09/02/21 00:28:13
>>162
ほら
URLﾘﾝｸ(www.kernel.org)
167:デフォルトの名無しさん
09/02/21 00:29:27
UNIXはC言語で組んだらしいけど、どうやったんだろ？
168:デフォルトの名無しさん
09/02/21 00:31:55
>>161
スタックポインタの設定って何だ？
引数の受け渡しのスタックポインタの操作はOSの機能ではなく、普通はアプリが自分でやるぞ？
169:デフォルトの名無しさん
09/02/21 00:33:04
>>166
boot/*.s の時点で boot してないじゃん
170:デフォルトの名無しさん
09/02/21 00:33:36
もしかして、OSが無いとコンパイラが動かせないから開発できないとか思ってる知的障害者がいるのかな。
171:デフォルトの名無しさん
09/02/21 00:39:06
>>168
それをアプリの中に書いてないでしょ
誰かが一度はその部分を書かないといけないわけで
それはCでは書けない
172:デフォルトの名無しさん
09/02/21 00:40:28
>>170
だから,
c で書かれた code のオブジェクトを startup させるために
最低限必要なレジスター設定をどうやった書くんだ?
って聞いてる
sp をどうやって設定するんだよ? どうやったって, アセンブラが必要だろ?
# それが c の拡張構文の中に収まっていたとしてもだ!!!
173:デフォルトの名無しさん
09/02/21 00:41:53
>>169
あ、ほんとだ。でもまあ、インラインで書けることには変わりないし。
174:デフォルトの名無しさん
09/02/21 00:42:27
>>171
>>170
175:デフォルトの名無しさん
09/02/21 00:43:16
>>172
インラインで書ける。
176:デフォルトの名無しさん
09/02/21 00:44:29
>>174
OSだとそれはあてはまらないのでは
177:デフォルトの名無しさん
09/02/21 00:44:49
>>175
だからぁ, 書いてる内容はアセンブリじゃんよ
178:デフォルトの名無しさん
09/02/21 00:45:36
>>175
君面白いね
179:デフォルトの名無しさん
09/02/21 00:46:37
こんな奴らに文句言われるLinusに同情するわ
180:デフォルトの名無しさん
09/02/21 00:50:47
>>172
Cの関数をアセンブラ・機械語に落とすと、
普通、関数の始まり・終わりにそれぞれスタックポインタ周りの初期化・後始末をするコードがつくけど、
コンパイラによっては、そういうコードを一切吐かないという指定が可能なの。
それ使って、あとは中からインラインアセンブリでスタックポインタの設定をすればいい。
181:デフォルトの名無しさん
09/02/21 00:52:24
>>180 だからぁ, 書いてる内容はアセンブリじゃんよ
182:デフォルトの名無しさん
09/02/21 00:52:29
>>177
インラインアセンブラに書くのも内容はアセンブリ言語だ。
>>147の
>インラインアセンブラというより生のアセンブラ必須
と言ったから、インラインアセンブラでもできるって言ってるんだろ。
183:デフォルトの名無しさん
09/02/21 00:53:45
>>181
だから、インラインに書けるだろ？
184:デフォルトの名無しさん
09/02/21 00:57:47
俺は>>172ではないが、>>157の話をしてるんじゃないのか？？？？
185:デフォルトの名無しさん
09/02/21 01:00:20
>>183
たとえば, lisp の source code 内に、文字列として c のソースを埋め込んで
c コンパイラで文字列をコンパイル/実行したとしするじゃん
こんな感じ
(compile-c-code "
;; 延々 c のコードが続く
")
(exec <上でコンパイルしたコード>)
これって, lisp のコードとはいわんぞ
186:デフォルトの名無しさん
09/02/21 01:02:53
>>174氏ね
187:デフォルトの名無しさん
09/02/21 01:04:18
cでさえこうなんだから、c++を排除したのは正解かも
188:デフォルトの名無しさん
09/02/21 01:05:24
>>187
火種になりそうな妙な事はもう言うなｗｗｗｗｗｗｗｗｗ
189:デフォルトの名無しさん
09/02/21 01:06:02
>>185
それをlispのコードと呼ばないかどうかはわからんが、
インラインアセンブラで書けるかどうかって話だろ？
>>172はインラインアセンブラで書ける。それだけ。
190:デフォルトの名無しさん
09/02/21 01:09:38
あほな論争にようやく終止符が打たれた
あとは>>160が死ねば一件落着
191:デフォルトの名無しさん
09/02/21 01:10:01
>>189 ある意味、処理系限定だけどな
192:デフォルトの名無しさん
09/02/21 01:11:25
>>191
処理系限定じゃないアセンブラってあるの？
193:デフォルトの名無しさん
09/02/21 01:12:40
>>187
GitがC++じゃないことに対する批判とLinusの反論とは別次元の話だよ。
boot strapをC++で書いたほうがいいと主張する奴は一人もいないだろう。
194:デフォルトの名無しさん
09/02/21 01:16:08
インラインアセンブラをCと解釈するってアホだろ
195:デフォルトの名無しさん
09/02/21 01:17:24
インラインアセンブラで書けるか、という議論を
インラインアセンブラはCか、と言う議論と解釈するってアホだろ
196:デフォルトの名無しさん
09/02/21 01:19:35
>>195
>>160のことなら逆じゃね？
197:デフォルトの名無しさん
09/02/21 01:20:51
逆ってどういう意味？
198:デフォルトの名無しさん
09/02/21 01:32:24
くだらない意地に時間を費やすより、せっかくの機会だから、いろいろ試したり
調べたりしてみては？
ワンチップマイコンを弄ってみたり、Cから呼ぶアセンブラの関数をいろいろ
書いてみたりとか。
Cでここまで書けるのかという発見もあると思う。逆に無理なことも。
メインフレームと呼ばれる大型コンピュータのCPUにはスタックが無いもの
も多い。じゃぁCのプログラムって、どうやって動かしているんだろうとか。
199:デフォルトの名無しさん
09/02/21 01:33:26
>>195はきちがい
200:デフォルトの名無しさん
09/02/21 01:34:22
言語の枠と拡張すら理解できない奴がなにやっても無駄
201:デフォルトの名無しさん
09/02/21 01:39:55
このスレのプログラマってC/C++で何のプログラム作ってるんだろう？
202:デフォルトの名無しさん
09/02/21 01:42:50
要点だけ列挙すると
inlineのアセンブラは処理系によっては何でも書ける
意地でも関数プロローグと関数プロローグを伯処理系も
存在するようだ
inlineのアセンブラにしたってCPU依存だ
アセンブリのソース直書きするんと、どこがちゃうのよ
そもそも, アセンブリコードが大半のCのファイルが
Cのソースと言えるのか?
".c"とか付いてる限りCのコードって言ってええんちゃう
ってな話？
だとしたら、どれを見てもCの規格の範囲からハズレてるんだから
Cですべてが書けるってのは嘘じゃん
203:デフォルトの名無しさん
09/02/21 01:44:40
ふと思ったんだけど、JavaVMみたいに「C実行環境」のようなものが無いと、Cのプログラムは動かせないとか思ってる知的障害者がいるのかな。
204:デフォルトの名無しさん
09/02/21 01:44:52
>>180
へぇー。なるほど
で、そういう指定はgccでも出来たりする？
ざっと見た感じでは無いみたいだけど、見落とし？
205:デフォルトの名無しさん
09/02/21 01:45:34
お前の妄想
206:デフォルトの名無しさん
09/02/21 01:47:19
>>202
流れとしては、Cのコードか？とか、Cでかけるか？と言う話ではなくて、
インラインアセンブラで書けるか？と言う話だよ。
207:デフォルトの名無しさん
09/02/21 01:53:16
>>203
それは誤解だ
JavaVMも仮想とはいえ、ちゃんとCPUでJavaでは書けない部分が存在する
その部分は隠蔽されているが JavaVMのアセンブラで書かれてある
208:デフォルトの名無しさん
09/02/21 01:54:02
>>204
インラインだったら何でもできるって騒いでる奴じゃないけど
gcc は 3.x の頃から、関数の中身がすべてインラインアセンブラ表現だと
勝手にそうなるよ
# CPUタイプにもよるんだけど…
でも、書いてる内容はアセンブリ以外の何者でもないけどね
まだ、".s"とか".S"をサフィックスにしてアセンブリコードって分かった
方が、コードベースのメンテナンスはやりやすい
209:デフォルトの名無しさん
09/02/21 01:58:44
>>204
__attribute__(naked)があるけど、一部の環境でしか対応していないみたい。
URLﾘﾝｸ(gcc.gnu.org)
210:デフォルトの名無しさん
09/02/21 02:01:03
>>207
日本語でいいですよ。
211:デフォルトの名無しさん
09/02/21 02:04:54
>>208 >>209
ありがとう
でも関数からのリターンをどうするんだろうね
インラインアセンブラでjmpしちゃうのかな
それと、結局はインラインアセンブラだけではOSは書けないケースが多いということか
212:デフォルトの名無しさん
09/02/21 02:05:50
>>157
>>160
どう考えても>>160がおかしいだろ。
213:デフォルトの名無しさん
09/02/21 02:06:40
Javaバイトコードには、普通にJavaプログラムをコンパイルするだけなら
おそらく使われないであろうものもあると言いたいのだろうが、
それと203との繋がりがよく分からない。
214:デフォルトの名無しさん
09/02/21 02:14:29
203が知的障害持ってるだけだろ
215:デフォルトの名無しさん
09/02/21 02:17:55
お題。
ISO/IEC 14882:2003とXLib、Win32APIの範囲内でスクラッチからエディタを作る。
Win32、XLibともに標準C++ライブラリとかぶる機能があるが、この場合
標準C++を優先して使う。
これは、少しでも移植性を高めるための努力と考えてほしい。
また、拡張性の担保ともなりうる。
これは時間かかるけど、やりがいあるよ？
216:デフォルトの名無しさん
09/02/21 02:22:49
>>215
Win32 は知らんが、Xlib って C バインディングじゃね?
つか、エディタ C とか C++ で作ろうと思わないんじゃね?
普通、拡張用の DSL 設計して最低限の機能をそっちに持たして
残りは DSL で実装しないか?
217:デフォルトの名無しさん
09/02/21 02:30:40
>>216
また極端な意見だな
218:デフォルトの名無しさん
09/02/21 02:31:09
上にスクリプトエンジンが乗ってると、
下はC++でなくてもCで十分だよな。
219:デフォルトの名無しさん
09/02/21 02:33:24
また奇天烈な話かよ
220:デフォルトの名無しさん
09/02/21 02:37:50
emacsに持っていくつもりかよ。
221:デフォルトの名無しさん
09/02/21 02:47:06
xyzzy とか vim とか………
222:デフォルトの名無しさん
09/02/21 04:03:58
メモリマップドIOならCから読み書きできる。
スタックまわりは無理だが、コンテキストスイッチやらなんやらの関数も当然あるから
記述はできるな。つーかＣのソースはアセンブラに変換されるんだから出来て当然というべきか。
223:デフォルトの名無しさん
09/02/21 09:16:27
>>211
何でそう言う結論になるんだか。。
224:デフォルトの名無しさん
09/02/21 09:21:39
>>212
>さすがにレジスタを直接イジるCの関数（は「生のアセンブラ」（>>147参照）でなければ）は無理だw （>>157）
↓
>インラインで書ける (>>160)
どう見ても>>160が正しい。
225:デフォルトの名無しさん
09/02/21 09:24:25
>>224
なんと言うエスパー
その超越した読解力はこのスレにはもったいない。消えろ。
226:デフォルトの名無しさん
09/02/21 09:31:12
>>225
じゃあ、君の解釈はどうなんだ？
>>224のように補完していいから分かるように説明しろ。
227:デフォルトの名無しさん
09/02/21 09:42:40
>>225が必死すぎてワロタｗｗ
まあ>>224もきちがい染みてるけどな
228:デフォルトの名無しさん
09/02/21 09:47:29
>>226
お前レベルの補完は書いた人間以外無理だろJK
229:デフォルトの名無しさん
09/02/21 09:52:07
>>228
だから、君はどう補完してどう解釈するのかを示せよ。
230:デフォルトの名無しさん
09/02/21 09:56:02
>>229
>さすがにレジスタを直接イジるCの関数は無理だw （>>157）
↓
>インラインで書ける (>>160)
これ以降インラインはCと言えるのかというアホ議論に発展
231:デフォルトの名無しさん
09/02/21 09:59:57
なるほど。
インラインアセンブラの話題で「インラインアセンブラ」を「インライン」と略したら
それを「インライン関数」と解釈したアホがいたってことか。
232:デフォルトの名無しさん
09/02/21 10:02:19
>>230
まあ、そうだな。
233:デフォルトの名無しさん
09/02/21 10:05:27
>>231
次から次へと真打が出てくるなｗ
その発想はなかった
ってかそんなレスがあったのかどうか
234:デフォルトの名無しさん
09/02/21 10:09:35
結論
>>143
はい。インラインアセンブラ必須です。
「生のアセンブラ」は必要ありません。
235:デフォルトの名無しさん
09/02/21 10:11:20
>>234
いや、Cで書ける
236:デフォルトの名無しさん
09/02/21 10:12:37
>>235
Cで書けるかどうかではなく、インラインアセンブラが必要かどうかを聞かれているんだけど？
237:デフォルトの名無しさん
09/02/21 10:14:03
>>236
ほら
URLﾘﾝｸ(www.kernel.org)
238:デフォルトの名無しさん
09/02/21 10:16:48
敗北した>>147がコピペ荒らしを開始したようだな。
239:デフォルトの名無しさん
09/02/21 10:19:33
無限ループって怖いね＞＜
240:デフォルトの名無しさん
09/02/21 10:51:10
__emit__ 組み込み関数と強制インライン関数を組み合わせたら
関数だけで何でも出来るよ
241:デフォルトの名無しさん
09/02/21 11:36:01
>>157がC（の関数で）レジスタがいじれないっていってるのに
Cの文法ではないインラインアセンブラで書けるって突っ込むからおかしいんだろ。
言ってること自体は間違ってないが>>157はCで書けないっていってるわけで
Cの文法でないインラインアセンブラでかけると言ってる突込みがおかしいと言われてるのに
自分のいってることは間違いではないの一点張り。
そりゃそうだけどそりゃ会話(レス)じゃない。
242:デフォルトの名無しさん
09/02/21 11:43:11
インラインアセンブラを使えば、Ｃの関数でレジスタをいじれるよ。
>>157の論点は「インラインアセンブラがＣの（標準化された）文法か」ではない。
単に「Ｃの関数でレジスタをいじれるか」だ。
243:デフォルトの名無しさん
09/02/21 11:48:18
>>241
>>143からの流れでインラインアセンブラの話をしているのに、
「Cの文法でないインラインアセンブラでかけると言ってる突込みがおかしい」と言う方がおかしいだろ。
244:デフォルトの名無しさん
09/02/21 11:48:56
つまり、>>147の言い分だと
WTLを使うと言う事は、アセンブラを使う事だって事か?
そ・ん・な・ば・か・な・!!!
245:デフォルトの名無しさん
09/02/21 11:57:57
あほばっか
246:デフォルトの名無しさん
09/02/21 12:00:26
>>243
>>143は
＞C言語の標準ライブラリ関数だけでは機能不足だから
＞インラインアセンブラ必須って理解でいいんですか？
とC標準の限界に言及してるんだからおまえがおかしい
247:デフォルトの名無しさん
09/02/21 12:03:16
>>242
お前独自の論点では会話は成立しない
248:デフォルトの名無しさん
09/02/21 12:31:32
まあ、>>147がバカだったってことで。
249:デフォルトの名無しさん
09/02/21 12:46:13
とりあえず、>>147が馬鹿だな
インラインアセンブラは必須だけど、生のアセンブラは要らない
250:デフォルトの名無しさん
09/02/21 13:58:59
アセンブラ
=> OSを含んだあらゆるソフトウェアが記述可能
C
=> 拡張機能のインラインアセンブラを使えばOSが記述可能
=> C標準関数等だけではOSの記述は不可能。
C++
=> C同様に拡張機能を使えばOSが記述可能。標準機能のみでは無理。
=> 標準でC互換なのでC言語の機能がすべて使用可(extern "C"もあるよ)
結論：
拡張機能も含めればC++最強！！！！！！！！
拡張機能を含めない場合はアセンブラ最強！！！！！！
251:デフォルトの名無しさん
09/02/21 14:16:32
asm ブロック自体は C の規格にあるわけだが
252:デフォルトの名無しさん
09/02/21 14:21:16
C++がウンコっていう命題からずれすぎ
253:デフォルトの名無しさん
09/02/21 14:36:37
つ [ISO C] [ANSI C]
254:デフォルトの名無しさん
09/02/21 15:01:53
滅多に使うべきでないパターンを簡単に使えるのが問題。
あるパターンが必要になる確率とそのパターンを使いたいと思う確率が一致しない。
255:デフォルトの名無しさん
09/02/21 15:10:46
>>251
ありませんが。
あるというなら規格のどの項だよ？
256:デフォルトの名無しさん
09/02/21 15:41:23
すまん。asm が規格にあるのは C++ だったわ。
257:デフォルトの名無しさん
09/02/21 15:42:14
asmはCじゃなくてC++の規格
しかもC++でも構文が決まってるだけで中身はimplementation-definedだから
asmの中にインラインアセンブラを書けるという保証は標準の範囲内にはない
258:デフォルトの名無しさん
09/02/21 15:44:48
インラインアセンブラを書けるという保証は無いが、
インラインアセンブラを書けても規格の範囲内だな。
259:デフォルトの名無しさん
09/02/21 17:02:52
アセンブラの話でC++がｳﾝｺな話をそらそうとする輩がうざい。
260:デフォルトの名無しさん
09/02/21 17:26:59
Linusはオブジェクト指向言語をウンコだとは言っていない、C++がウンコだと言っているだけ。
そして実際にC++はウンコ。
261:デフォルトの名無しさん
09/02/21 17:44:40
C++よりウンコじゃないオブジェクト指向言語ってあるの？
程度と方向性の違いはあってもクソばっかりじゃん
262:デフォルトの名無しさん
09/02/21 17:47:50
C#は神
263:デフォルトの名無しさん
09/02/21 17:49:53
まあ、ウンコウンコいってるやつにとっては
現実世界もきっとウンコに違いない。
ウンコな世界にいるのは精神衛生上よくない。
あなたの望む世界へ旅立つ事をお勧めします。
264:デフォルトの名無しさん
09/02/21 17:51:43
きっとハエなんだよ
265:デフォルトの名無しさん
09/02/21 18:51:19
俺もC++使うけど、なんだかんだ言ったってCが一番落ち着くｗ
266:デフォルトの名無しさん
09/02/21 20:09:38
デストラクタが無いと落ち着けないわ・・・
267:デフォルトの名無しさん
09/02/21 22:03:34
>>266
たかがそんなことで落ち着けないなんて・・・
素人そのものだねｗ
268:デフォルトの名無しさん
09/02/21 22:57:41
Objective-Cは間違った進化をしてるとしか思えない
269:デフォルトの名無しさん
09/02/21 23:01:53
例えば？
270:デフォルトの名無しさん
09/02/21 23:03:29
Objective-Cはちょっと構文見ただけで吐き気がしてくる。
気持ちが悪い。
これはCを語っちゃいけない言語だと思う。
271:デフォルトの名無しさん
09/02/21 23:08:33
C#とObjective-Cだとどっちだよ。
272:デフォルトの名無しさん
09/02/21 23:12:00
c#の圧勝
273:デフォルトの名無しさん
09/02/21 23:13:12
>>271
較べるなんておこがましい。
C#は大成功
Objective-Cは大失敗
274:デフォルトの名無しさん
09/02/21 23:13:36
>>270
Cの完全上位互換ですが?
275:デフォルトの名無しさん
09/02/21 23:19:06
>>273
単にWindowsとMacの差だと思う
iPhoneやその周辺次第によっちゃObjective-Cもこの先あなどれない
276:デフォルトの名無しさん
09/02/21 23:21:34
構造化プログラミングのC言語をマクロ構文みたいなキーワードを追加して
無理矢理オプジェクト指向プログラミングを実現している
277:デフォルトの名無しさん
09/02/21 23:22:16
漏れもObjective-Cはいただけない。
構文が泥縄的、あるいは取って付けたと形容するに相応しい。
Cとの互換性はヘッダを取り込み、objを吐ければ十分なんだから
Cの構文をそのまま内包する必要は無い。
278:デフォルトの名無しさん
09/02/21 23:22:27
>>275
プラットフォームは関係ない。
ライブラリでも実行バイナリでも比較していない。
純粋に言語仕様の差だ。
279:デフォルトの名無しさん
09/02/21 23:24:42
C/C++ カレーはご飯とルーに分けて食べるタイプ
Objective-C カレーはご飯とルーをぐちゃぐちゃに混ぜてから食べるタイプ
280:デフォルトの名無しさん
09/02/21 23:25:06
C++もObjective-CもC#も
方向性が違うだけでウンコ度は一緒
281:デフォルトの名無しさん
09/02/21 23:27:04
>>279
違うだろ
カレー（C）に福神漬け（オブジェクト指向）を乗せたのがObjective-C
カレーの具に福神漬けを入れて煮込んじゃったのがC++
282:デフォルトの名無しさん
09/02/21 23:46:04
カレー→シーフードカレー的進化がC++、
カレー→エビフライカレー的進化がObjective-C。
後者は、乗っかってるエビフライのビジュアルに問題がある。
283:デフォルトの名無しさん
09/02/21 23:55:43
URLﾘﾝｸ(sourceforge.jp)
C++結構人気ないね・・・
284:デフォルトの名無しさん
09/02/22 00:00:26
2CH憲章
・奇天烈な書き込みで合意を得られると喜ばしい。
285:デフォルトの名無しさん
09/02/22 05:41:21
イメージとしてはこうかな
Objective-C カレーソースとライスが分かれてる（上品な感じ）
C++ カレーうどん（大衆的な感じ）
286:デフォルトの名無しさん
09/02/22 10:20:21
Objective-C: ご飯の上にカレーうどん用のカレーぶっかけちゃった感じ
C++ ご飯に普通のカレー入れたけど、ぐちゃぐちゃにかき混ぜちゃった
287:デフォルトの名無しさん
09/02/22 10:47:12
大阪にはご飯の入ったカレーうどんがあるんだぞ
288:デフォルトの名無しさん
09/02/22 11:38:54
>>283
スタンドアロンならjavaのがライブラリがそろっていて楽だし、
ライブラリつくるならどうせCリンケージで出さないといけないのでCのがよい
って感じでしょ。
289:デフォルトの名無しさん
09/02/22 13:55:17
C++ ご飯とカレーの材料を置いてるだけの感じ（お前ら好きにしろ）
Objective-C: 必死になってるだけ
290:デフォルトの名無しさん
09/02/22 14:22:22
C ご飯とカレー
C++ ご飯とカレーにいろんなスパイス並べて好き勝手スパイス入れてから客に出す
291:デフォルトの名無しさん
09/02/22 14:35:04
Cは米や肉などの材料で薪集めてカマド作るところから始めていく
C++は上記に微妙に便利なアウトドアグッズが揃っている
292:デフォルトの名無しさん
09/02/22 14:47:05
柄に刃が付いたナイフや底に穴の開いた鍋が揃ってるんですね、わかります
293:デフォルトの名無しさん
09/02/22 17:17:21
柄と刃の区別もつかないバカは料理しちゃいけませんでちゅよー。
294:デフォルトの名無しさん
09/02/22 17:22:53
実際そういうレベルの人がアウトドアしてるんだよね。
そいつらにバカはアウトドアすんなというと仕事が回らなくなる矛盾。
295:デフォルトの名無しさん
09/02/22 17:31:30
ソフトウェア開発に限っていえば日本はバカが得をする国だからね。
C++なんか流行らん訳だ。
296:デフォルトの名無しさん
09/02/22 18:23:07
まるで日本以外ではC++が流行っているかのような口ぶりだな
297:デフォルトの名無しさん
09/02/22 18:42:58
Cで８年くらい仕事して、C++にして6年仕事してるけど
C++のメリットよりもデメリットが大きい印象変わんないな。
298:デフォルトの名無しさん
09/02/22 19:40:34
柄の所になぜか刃が付いてて握ると手をケガするようなライブラリが
C++にはいっぱいあるという皮肉も通じないのか
299:デフォルトの名無しさん
09/02/22 19:51:44
ライブラリ？
300:デフォルトの名無しさん
09/02/22 20:06:57
「柄」の所になぜか刃が付いてて「刃」の所になぜか刃がついてないんだろ？
「柄」と「刃」を取り違えてるんだよバーカ、という皮肉も通じないのか
301:デフォルトの名無しさん
09/02/22 20:08:08
ライブラリ？
302:デフォルトの名無しさん
09/02/22 20:14:28
標準ライブラリだよ
たとえばauto_ptrなんて全方向に刃が付いてるじゃないか
どこ持ってもケガする最低のライブラリ
303:デフォルトの名無しさん
09/02/22 20:23:00
いやライブラリ以前にもたくさん問題がｗ
304:デフォルトの名無しさん
09/02/22 20:39:40
302が鬼の首をとったが如くlist<auto_ptr>の話をしだすのに
100 iostream。
305:デフォルトの名無しさん
09/02/22 20:46:05
日本ではというか、C++は窓以外閑古鳥だろ。
unixに至っては数ある有象無象言語のひとつ。
306:デフォルトの名無しさん
09/02/22 21:12:45
そう思っていても使わざるを得ない状況がある以上、習得するしかなかべ。
プログラマは言語選ぶ権利ないし。
307:デフォルトの名無しさん
09/02/22 21:33:37
まあ下っ端とか、請負プログラマはそうだろうね
308:デフォルトの名無しさん
09/02/22 21:45:42
つまりうわっぱプログラマはC++も使えないカスばかり、と。
309:デフォルトの名無しさん
09/02/22 21:49:10
C++使いこなしているからこそC++はイイとかダメとかいえるに決まってるじゃないか。
みんなプログラミング言語C++を3回は通して読んだレベルだよ。
310:デフォルトの名無しさん
09/02/23 02:23:32
>>309
ほとんどネットでその半分が2chだなぁ。
auto_ptrって使ったことないな。そもそもnewしないからなぁ。
総括のクラスをスタックに確保してアプリ完成！って感じだな。
実用アプリってほとんど作ったことないけどね。
311:デフォルトの名無しさん
09/02/23 08:21:00
大きなアプリ書こうとするとnewは必要だよ。
モジュール・タスク分割してそれらの間のAPIを書くのに
newを使うか否かでシンプルにも複雑にもなる。
newをつかって例外安全に書くんならauto_ptr必須。
312:デフォルトの名無しさん
09/02/23 08:28:01
コンテナに入れられない時点でauto_ptrは使い物にならない。
313:デフォルトの名無しさん
09/02/23 08:32:32
auto_ptrなんて使えないものを作った奴と標準に含めた奴は切腹しろ
314:デフォルトの名無しさん
09/02/23 08:52:39
>>312
想定する用途が違うだけなのに、自分が使いたいときに使えないというだけで
ダメ扱いするのは頭悪いんじゃない？
次の標準ではお前の欲しかった shared_ptr も入るよ。
315:デフォルトの名無しさん
09/02/23 09:08:05
std::ｖｅｃtor obj(sizeof(hoge) * n);
hoge *pobj = &obj[0];
で十分
316:デフォルトの名無しさん
09/02/23 09:41:13
>>315
中身を解放しませんよ。
ま、ヒープの問題はCでもsetjump longjumpを知らないところで使われたら一緒だし目くじらたてるほどのものかと思う。
317:デフォルトの名無しさん
09/02/23 09:52:28
>>315
釣られてみるが、
std::vector<hoge> obj(N);
でやらないメリットってなんだい？？
318:デフォルトの名無しさん
09/02/23 20:36:15
>>317
コピーコンストラクタ（爆）を律儀にN回呼んで
貴重な実行時間を食いつぶすから
319:デフォルトの名無しさん
09/02/23 20:46:03
>>318
???
320:デフォルトの名無しさん
09/02/23 21:00:49
>>318
すまん。俺もわかんね。
>>315だとコピーコンストラクタ呼ばれないの？
321:デフォルトの名無しさん
09/02/23 21:18:45
>>317
クラスの不変条件を達成するにはクラスのメンバ変数を初期化しないといけない。
そのためにはコンストラクタは呼ばれるべきでしょ。
俺の場合だけど、コンストラクタは適当に書いて、Init()ってメンバ関数で本格的に初期化してる。
再利用できるようにも一応考えてつくってる。
あ、また、ミリセカンドでチューニングしてる人か。
322:デフォルトの名無しさん
09/02/23 21:25:35
>>320
C++を覚えたばっかりで、良く分からないんだが
>>315だとコピーコンストラクタは呼ばれない(というか、たぶん、コンパイルできない)
323:デフォルトの名無しさん
09/02/23 21:31:23
std::vector<hoge> obj(N, hoge(1, 2));
と書くと、各要素がhoge(1, 2)でコピー初期化される。
>>317は、それがデフォルト引数で省略されているだけ。
>>315はおそらくstd::vector<char>だろうが、
charの初期化なら実行時間が少しはましだったのだろう。
コンパイラが賢ければ、315のようにcharに置き換えて良い型
（コンストラクタがない）なら、
hogeのままでもそう時間は変わらないことが期待できるけど。
一応、次の規格では改善されて、デフォルト引数使う横着はなくなるので、この心配はなくなるはず。
324:320
09/02/23 22:06:29
>>322-323
レスさんくす
325:デフォルトの名無しさん
09/02/23 22:26:45
アホの妄言には付き合ってられんわ
326:デフォルトの名無しさん
09/02/23 22:37:37
>>323
で、結論は？
327:デフォルトの名無しさん
09/02/24 00:05:44
結局、C++一通りやったプログラマってHSPに原点回帰するんだよな。
俺の知り合いも、ついこの間C++の仕事辞めて今はHSPでフリーウェア作ってる。
328:デフォルトの名無しさん
09/02/24 00:31:15
それはない。そもそも原点じゃないし。
329:デフォルトの名無しさん
09/02/24 01:54:46
>>327ないしその「知り合い」とやらが初めに触った環境なんだろ。察してやろうぜ
330:デフォルトの名無しさん
09/02/24 12:34:33
>>323
＞デフォルト引数使う横着はなくなる
どういうこと？
331:デフォルトの名無しさん
09/02/24 13:35:42
vectorはresizeできるのに、
vector<hoge> obj(N);とサイズ決め打ちで確保してるのは横着じゃないの？
332:デフォルトの名無しさん
09/02/24 15:24:29
>>331
大きさが既に分かっているなら
vector<hoge> obj(N);
の方がいいんじゃないの?
333:デフォルトの名無しさん
09/02/24 16:54:00
>>332
コンストラクタに時間を取られるので、なるべく呼びたくない、
という話だから。 >>318
334:デフォルトの名無しさん
09/02/24 17:30:38
>>333
resizeしても、コンストラクターは呼び出されるだろ?
335:デフォルトの名無しさん
09/02/24 17:44:36
>>334
最後まで参照されない要素はコンストラクトしないで済む。
336:デフォルトの名無しさん
09/02/24 18:02:30
>>331
細かい話だが、サイズが最初からわかってるなら、決め打ちしたほうがメモリ確保回数が減るので多少マシだと思う。
337:デフォルトの名無しさん
09/02/24 18:11:35
>>336
大きさの上限が分かってるケースと、
全ての要素が参照されるケースを区別できるようにした方が良いよ。
reserveも使えるようになってね。
338:デフォルトの名無しさん
09/02/24 18:43:07
あれは構造体のmallocの代わりじゃないの？
339:デフォルトの名無しさん
09/02/24 19:14:09
>>330
>>331
323じゃないけど
現状の規格で
explicit vector(size_type n)のシグネチャで呼ばれるコンストラクタが
explicit vector(size_type n, const T& value = T(),
const Allocator& = Allocator());
のようなデフォルト引数による実装になっているのが
横着といいたいんじゃないの？
Tのデフォルトコンストラクタがinlineで何もしない実装の場合
新しい規格なら要素ごとにT()が呼ばれるから実質コンストラクタ
呼び出しのオーバーヘッドがなくせる。
340:デフォルトの名無しさん
09/02/25 01:15:19
すぐこういう話になるからC++はダメなんだよ
コンストラクタだのデストラクタだの知らない所で勝手にコソコソ余計なことやる奴が多すぎて
Cならそんなこと考える必要もないのに
341:デフォルトの名無しさん
09/02/25 01:37:01
STLの実装に噛みつくなんてどんだけ世間知らずなド素人なんだよｗｗ
342:デフォルトの名無しさん
09/02/25 01:43:55
Cはsize_tを画面に出すだけでも破綻するけどね。
343:デフォルトの名無しさん
09/02/25 01:48:16
DWORD
344:デフォルトの名無しさん
09/02/25 01:56:50
>>340
今時、どっちもどっちだと思うぞ
算数の計算のしかたもしらん多すぎ！
数値計算やらせると、誤差とか桁落ちとか理解してねぇもん
つか、仕様として数式与えられた時点で、ほぼ全員アウトだろ？
345:デフォルトの名無しさん
09/02/25 01:57:34
floatの仕組みを理解してる奴が少ない現実。
346:デフォルトの名無しさん
09/02/25 07:51:29
float関係ないんじゃね?
正数演算であっても
x/y * z があえられたときに正直に
(x / y) * z って計算する奴多くね?
347:デフォルトの名無しさん
09/02/25 10:18:03
じゃあ、それってx*z/yが正しいの？桁堕ちの誤差で？
348:デフォルトの名無しさん
09/02/25 10:42:24
floatの仕組みなんて文理関係なく大学の教養で必修としてやるだろ。
少なくとも東大ではそうだ。
349:デフォルトの名無しさん
09/02/25 11:05:20
いまどきは知らんが、20年ほど前は教養でそんなことやらんぞ。
専門の講義で数値解析やるときくらいかね(高校の授業にコンピュータとかない時代だから、まあ当然か)。
それ以前に、その時代にパソコン触ってた連中はBASICの入門書とかで0.1を10回足して1にならにでしょ、みたいなの見てるから、むしろそっちで知ってるはず。
MSXはBCDだからちゃんと1になるよ～とかね。
350:デフォルトの名無しさん
09/02/25 12:00:51
>>349
何処の田舎の話だよ
工業高校の電気科だが、20年前、普通に浮動小数点がどうのBCDがどうのやったぞ
まあ、当時の俺様にはさっぱり理解できなかったがな
351:デフォルトの名無しさん
09/02/25 12:11:05
double d1 = 1.0 - 0.9;
double d2 = 1.0/10.0;
assert( d1 == d2 );
うぼぁ。
352:デフォルトの名無しさん
09/02/25 12:49:27
>>339
でもとにかくオブジェクトの構築は絶対に
必要なんだから、いずれコンストラクタは
呼び出されるでしょ？
コンテナのコンストラクタでわざわざ格納
オブジェクトのコピーコンストラクタが
呼び出されていたのがなくなるということ？
ちょっとした改善？
353:デフォルトの名無しさん
09/02/25 12:55:55
>>350
いやオレもやらんかったな。
普通大学の一般教養にはないだろ。
有効桁なら高校以下の理科で習ったが。
＞工業高校の電気科
だからやったんじゃね。ちょっと特別。
354:デフォルトの名無しさん
09/02/25 13:02:52
>>350
京都大学の話。
355:デフォルトの名無しさん
09/02/25 13:10:59
田舎でおｋ
356:デフォルトの名無しさん
09/02/25 13:47:44
>>352
デフォルトコンストラクタ（場合によっては＋代入）と、コピーコンストラクタでは、
パフォーマンスが違うことがあり得る、という話。
357:デフォルトの名無しさん
09/02/25 14:17:06
高校レベルの話を大学でやらないとは...
358:デフォルトの名無しさん
09/02/25 14:28:44
>>357
高校でやってれば大学でやる必要ないのだが？
359:デフォルトの名無しさん
09/02/25 14:56:23
で、たとえば>>351みたいな assertion failed を起こさないようにするには
C/C++/java などではどんなライボラリを使えばいいのか答えなさい（涼宮ハルヒ風に^^）
360:352
09/02/25 18:35:17
>>356
それはわかる。
格納オブジェクトのコンストラクタがコピー
コンストラクタよりも軽い場合に、コンテナの
コンストラクトが速くなる、ということでおＫ？
361:デフォルトの名無しさん
09/02/25 19:06:55
>>360
おけ。
改めて調べてみたら、C++0xだと、コピーできないオブジェクト
（コピーコンストラクタも代入も無し）が一般的になりそうな感じが。
C言語との乖離が広がって、Linusさんがまたぼろくそにけなしそう。
362:デフォルトの名無しさん
09/02/25 19:26:15
現時点でもfstreamとかauto_ptrとか、
あるいは自作クラスでもコピー禁止にするものが多いよ。
JavaなんかでなんでもかんでもCloneable実装しないのと根は同じ。
コピーして自由に持ちまわれるようにするには、
ポインタ（生でもshared_ptrでも）にしまうのは今でも0xになっても同じ。
いやまあ、コピー不可でもvectorに直接入れられるとか、変化はあるけど。
363:デフォルトの名無しさん
09/02/25 20:09:09
まあそうっちゃそうなんだけど。
=deleteで{デフォルト|コピー}コンストラクタがないことを明示できたり。
emplaceでpush_backと同時にコンストラクトできたり。
move semanticsが導入されたり。
で、今まで、コーディング上のテクニックですよ、みたいな感じで
使っていたコピー禁止オブジェクトが、言語で手厚くサポートされた
第1級のオブジェクトになったような風向き。
364:デフォルトの名無しさん
09/02/25 22:19:58
笑えるスレだな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:デフォルトの名無しさん
09/02/25 22:21:55
コピーコンストラクタと代入演算子を意味もなく特別扱いしてきたツケを払ってるだけだろ
コピーなんてのは必要な時にだけ用意する操作でいいのに
366:デフォルトの名無しさん
09/02/26 00:30:35
>>365
structとclassの違いがデフォでpublicかprivateかの違いしか持たせなかったのが根本原因だね。
367:デフォルトの名無しさん
09/02/26 01:28:27
typedef double Real;
とかやる奴とは一緒に仕事したくない。Realはないだろ。。。
368:デフォルトの名無しさん
09/02/26 01:40:43
real型を組み込みで持つDという言語があってな…
369:デフォルトの名無しさん
09/02/26 06:22:50
いや、Real型と言えば、Pascalのほうが先だろう。
370:デフォルトの名無しさん
09/02/26 09:20:36
>>362
＞コピー不可でもvectorに直接入れられる
再配置はどうなるの？
371:360
09/02/26 09:23:36
>>361
はあく。あり。
じゃあメリットは現実にはあんまりなさげ。
372:デフォルトの名無しさん
09/02/26 09:31:35
>>365
C++がここまでの領域に達するとは、
当時に予測することは不可能。
最初はCの薄喇叭だったんだし、
PODとの互換を重視したのはやむなし。
>>366
そのへん、後発のC#はさすが。
373:デフォルトの名無しさん
09/02/26 10:38:39
>>365,366
C言語のコピー渡し大好き仕様にあわせたのが原因。
374:デフォルトの名無しさん
09/02/26 13:41:22
>>364
よく >>347 みたいな曖昧な質問に答えられるな。
>>347が
桁落ちの誤差の範囲内で正しいのか？と聞きたかったのか、
桁落ちの誤差があるのに正しいつもりか？といってるのか。
未だにわからん。
それに、xの値が大きいときの話が抜けてるよ。
375:デフォルトの名無しさん
09/02/26 14:26:06
そもそもの前提の仕様としてx/y * zが渡されるってとこでもうダメだろ。
必要な精度も何も書いてないんだから
376:デフォルトの名無しさん
09/02/26 14:33:05
型も書かれてないしな
377:デフォルトの名無しさん
09/02/26 14:37:30
素人は
他人のアラだけ
よく見える
378:デフォルトの名無しさん
09/02/26 20:38:30
>>370
そのタネがムーブセマンティクス。
新たにvectorに入れられるようになるのは、
auto_ptrのようなコピーがダメでも移すだけならいいでしょうという型。
（auto_ptr自体は非推奨で放置プレイだからvectorに入れられないままみたいだけど）
379:デフォルトの名無しさん
09/02/26 21:57:36
うーん。
Cと同様にメモリ管理はプログラマサイドに丸投げなくせに、ムーブやらなにやら中途半端に導入されてもなぁ。
そこまでやるならガベコレまで面倒見ろという感じ。
380:デフォルトの名無しさん
09/02/26 22:32:33
>>379
丸投げじゃない。
deleteを書かなくていいように進化してる。
381:デフォルトの名無しさん
09/02/26 22:34:44
>>379
ガベコレさえ取り込もうとしているからおそろしい。
いろんな意味で。
382:デフォルトの名無しさん
09/02/26 22:59:35
>>380
書かなくても、意識しないといけない時点でプログラマに責任を負わせてるでしょ。
383:デフォルトの名無しさん
09/02/26 23:12:22
ムーブはむしろコードの手間は増えても効率上げたいっていう機能だろ
GCとは思想が逆
384:デフォルトの名無しさん
09/02/27 01:03:41
URLﾘﾝｸ(up2.viploader.net)
おまいらwww
385:デフォルトの名無しさん
09/02/27 01:39:40
>>382
意識したくてもできない言語よりずっと頼りになる。
386:デフォルトの名無しさん
09/02/27 04:01:58
気が向いたら中を見たいけど、普段は見たくないって香具師に向いてる気がする。>C++
387:デフォルトの名無しさん
09/02/27 08:49:18
>>378
＞そのタネがムーブセマンティクス。
なるほど。豚。
ムーブってなんだろ、と見るたびに疑問
だったんだけど、そうゆうことなのね。
使いどころが難しそう。
388:デフォルトの名無しさん
09/02/27 09:01:57
>>385
ならcでいいや
389:デフォルトの名無しさん
09/02/27 09:45:45
実際、２ｃｈ(匿名)で件の文章だけ見たら、「馬鹿なこと言ってら、こいつ」って思う内容でしょ？ 本人に高いスキルがあっていろんな功績、貢献がある人物でも、個々の言動の評価はまた別。
ちなみに無知であること自体を非難するつもりは毛頭無いです。さすがに私もそこまで愚かじゃありません。
たぶん、malloc/reallocだけでの動的メモリ管理云々の文章を読んだことがあるということはその人のブログなりなんなりを見たことがあるんだと思うけど。
390:デフォルトの名無しさん
09/02/27 10:15:56
>>388
がんばって{c|m|re}alloc/free書いてね。setjump/longjumpにも気をつけてね。
391:デフォルトの名無しさん
09/02/27 10:29:08
>>390
ミスってるぞ
392:デフォルトの名無しさん
09/02/27 10:30:28
Cなら、malloc/freeが内部で呼んでるbrk/mmapでメモリ管理ライブラリ書いたほうが楽。
完璧に一元管理できるし。
393:デフォルトの名無しさん
09/02/27 10:39:57
>>392
移植も再利用も考えないなら、なんぼでも手抜きできるやん。
わざわざヒープ解放しなくても、プログラムが終了したら勝手に解放されるし！みたいな。
394:デフォルトの名無しさん
09/02/27 10:48:13
移植なら、マクロでmallocに置き換えるだけ。
それより、ライブラリのなか全部知りたいだけ。
395:デフォルトの名無しさん
09/02/27 10:54:18
>>394
で、そのマクロとやらで問題が起きたら「知るかそんなの」でしょ。
その調子でvtblやら例外（のまねごと）やら、全部自前で実装するべし。応援するよ。
396:デフォルトの名無しさん
09/02/27 11:01:43
それはありがとう。
OSやTCP/IPスタック書くのも勉強になるし。
397:デフォルトの名無しさん
09/02/27 12:34:31
10年後
396「Linuxプログラマはウンコ。寄ってくるな」
398:デフォルトの名無しさん
09/02/27 12:39:22
share_ptrやauto_ptrでも問題でたら（使い方間違ってたとかで）
「知るかそんなの」でしょ
同じだよ所詮
399:デフォルトの名無しさん
09/02/27 12:52:54
>>398
（問題点も含めて）ちゃんとドキュメントされてる。
テストされてる。パフォーマンス、データ型に対する汎用性、移植性も考慮されてる。
400:デフォルトの名無しさん
09/02/27 13:30:21
知るかそんなの
401:デフォルトの名無しさん
09/02/27 13:31:11
４０１
402:デフォルトの名無しさん
09/02/27 13:35:49
C++プログラマは人間のクズ、死ねよ
403:デフォルトの名無しさん
09/02/27 14:21:02
よく使われるマクロの置換ぐらいで目茶苦茶な反論してくるC++信者はキチガイだな。
そもそもCに寄生しないと生きていけないC++のくせにｗ
404:デフォルトの名無しさん
09/02/27 14:42:15
C++信者はキチガイ
近寄るべからず
405:デフォルトの名無しさん
09/02/27 15:17:44
>>390
皮肉にもなってない…
白ける
406:デフォルトの名無しさん
09/02/27 15:35:23
要するに
「俺よりバカなヤツと、俺より頭の良いヤツ(俺の理解できない手法を使う)は来るな」
という意味だよな。
407:デフォルトの名無しさん
09/02/27 15:41:07
>>1-406
負け犬遠吠え
408:ウンコなスレは停止しました。。。
09/02/27 16:44:18
真・スレッドリスターター。。。(￣ー￣)ﾆﾔﾘｯ
409:デフォルトの名無しさん
09/02/27 17:23:29
真実上げ
410:デフォルトの名無しさん
09/02/27 19:51:37
>>398
それでも問題出る人用のも出来てきてる
411:デフォルトの名無しさん
09/02/28 01:48:29
C++厨は無闇にマクロ嫌ってる奴が多いけど
正直連中が使ってるテンプレートなんかよりCの素朴なマクロの方が
ずっと明快だし、安全だし、高速だし、使いやすいよな
412:デフォルトの名無しさん
09/02/28 03:00:30
マクロ安全だと思ってるCプログラマはいないだろ
ロベールさんだって怖いって言ってたよ
413:デフォルトの名無しさん
09/02/28 04:43:16
Write in C
URLﾘﾝｸ(www.youtube.com)
414:デフォルトの名無しさん
09/02/28 08:29:36
>>411
テンプレートにたいして明快だと思えない人間に、マクロトリックを使ってほしくないね。
415:デフォルトの名無しさん
09/02/28 08:51:07
マクロは複数行で \ つけるのが鬱陶しい
416:デフォルトの名無しさん
09/02/28 11:11:20
>>415 エディタがマクロの範囲を判断して適当にくっつけてくれるだろ?
417:デフォルトの名無しさん
09/02/28 11:17:11
>>415
鬱陶しいなら、改行文字と同じように、￥も非表示にすればいいんじゃね？
418:デフォルトの名無しさん
09/02/28 11:47:03
可変引数テンプレートを実装する為とかforwarding problemの解決の為にマクロは必須
C++厨というかテンプレート厨は同時にマクロ厨でもある
419:デフォルトの名無しさん
09/02/28 12:01:34
マクロがテンプレートより優れている４つの理由
#明快さ
マクロの意味はマクロ名だけで明確に決まるので、定義を追いやすい。
また、大抵のコンパイラではプリプロセスだけ行うことができるので実際にどう展開されてるか確認できる。
引数に依存した複雑な推測をコンパイルと一緒にやってしまうテンプレートにはどちらも叶わぬことである
#安全
マクロは括弧を十分に付けることと、#undefや二重定義にさえ注意すれば、大抵は思った通りに展開される。
一方テンプレートが思った通りに展開されないのは日常茶飯事である。
#高速
マクロは単なるテキスト置換なので極めて高速に行える。
テンプレートはパーシングの負荷はもとより、再帰のせいで止まらないことすらある。
#使いやすさ
マクロの定義はやりたいことをがそのままテキストとして書かれる。
テンプレートは特殊化、SFINAEを乱用した恐ろしく回りくどいコードになる。
420:デフォルトの名無しさん
09/02/28 12:19:06
安全 の項は何が安全なんだろ。
421:デフォルトの名無しさん
09/02/28 12:49:31
少なくとも型に関してはまったく安全じゃないな
422:デフォルトの名無しさん
09/02/28 12:52:27
さらに展開されてからエラーになることによるエラー箇所の特定の難しさ、と
テンプレートがらみの鬼のようなエラーログ
ユーザに対する負担はいい勝負だな
423:デフォルトの名無しさん
09/02/28 13:12:35
テンプレートはエラーが出ても意味不明で結局対処できないからな。
0xでエラーメッセージが改善されることに期待だ。
424:デフォルトの名無しさん
09/02/28 13:54:01
C++をろくに知らないC使いが文句言うだけのスレになってる。
>>1のおっさんが、そうでないことを祈るしかないな。
425:デフォルトの名無しさん
09/02/28 14:07:02
文句いうなら対案を出せってか
少なくともGitに関してはCだけで十分みたいだから対案を出す必要はない
むしろCだけでは不十分な具体例を出す必要があるんじゃないか
426:デフォルトの名無しさん
09/02/28 14:42:58
>>424
linusを知らないことは無いだろう
427:デフォルトの名無しさん
09/02/28 14:50:15
linusが知らないことはあるだろうけどな
428:デフォルトの名無しさん
09/02/28 14:53:19
>>425
>>1のおっさんがLinusの言葉の一部を切り取って煽ってるだけ。
対案。>>1を以下に書き換える。
「唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったとき」
Linus
429:デフォルトの名無しさん
09/02/28 15:28:09
適材適所ってやつだよ。
Cが好きでCばっかりやるのは自由だ。
C++を批判するなら、C++を極めてからにしてくれｗｗ
まともに使えないウンコがいくら集まってもウンコなんだよww
430:デフォルトの名無しさん
09/02/28 15:29:59
C++って「ぼくのかんがえたさいきょうのげんご」的な厨房臭さがあるからなぁ
431:デフォルトの名無しさん
09/02/28 15:31:27
最強言語？なにそれ・・・ばっかじゃないのｗｗ
432:デフォルトの名無しさん
09/02/28 15:31:55
最強言語？なにそれ・・・ばっかじゃないの？ｗｗ
433:デフォルトの名無しさん
09/02/28 15:38:19
>>431,432
アンタがどこかしら弱いのだけはよく分かった。
434:デフォルトの名無しさん
09/02/28 15:39:12
>>433
やっぱり、ウンコはウンコだな
435:デフォルトの名無しさん
09/02/28 15:39:55
あ、めんごめんご、ウンコ以下ですね
436:デフォルトの名無しさん
09/02/28 16:15:32
>>418
どっちもC++0xでマクロ使わずに解決しようとしている辺り、
C++陣営はよっぽどマクロが嫌いらしい。
しかし、マクロなしではどうせやっていけるわけないのだから、
ようするに単なるツンデレだろう。
437:デフォルトの名無しさん
09/02/28 16:18:10
インクルードガード以外にマクロは不要
438:デフォルトの名無しさん
09/02/28 16:46:42
ライブラリやシステムコールでマクロ使いまくり
そもそもC++でCの機能使いまくりのC++厨は死ねよ
439:デフォルトの名無しさん
09/02/28 16:52:56
その理屈はよくわからない
440:デフォルトの名無しさん
09/02/28 16:59:31
C++厨はマクロの__FILE__や__LINE__使ったら自殺するらしいｗ
441:デフォルトの名無しさん
09/02/28 17:15:13
boostのassert系の関数では使われまくってるな
442:デフォルトの名無しさん
09/02/28 17:42:16
でもさ、移植性を気にして
#ifdefでマクロをバシバシ切り替えているのって結構あるぜ。
あれ超ウゼー。
443:デフォルトの名無しさん
09/02/28 18:37:24
Cで移植性の高いプログラムを書けるのはひとえに#ifdefのおかげ
あれなしに別々のコンパイラ特有のコードを混在させることはできない
444:デフォルトの名無しさん
09/02/28 18:56:01
Linusクラスの人間がC++プログラマはウンコっていうなら納得するが
おまえらに言われてもな。おまえらがウンコだろって言われて終了。
445:デフォルトの名無しさん
09/02/28 19:05:02
>>437
おれはpragma once好きなんだけど、みんな嫌がっているんだよな。
この辺の変なこだわり（色々と理由があるのは理解するけど）が
C++のいやらしいところだなあ。と思ってみたり。
446:デフォルトの名無しさん
09/02/28 20:26:45
pragma onceを万が一インクルードガードに
書き換えなきゃならなくなったときのことを考えたら、
そりゃ嫌がられるさ。
447:デフォルトの名無しさん
09/02/28 20:41:08
両方書いとけばいいんだよ。
面倒くさい？全くもってそのとおりです。
448:デフォルトの名無しさん
09/02/28 21:51:58
釣りのためにLinuxまで作ってしまったLinusだが、Gitでは逆に作ってから
釣りあげられてしまったね。
笑える。
因果応報だよ。
449:デフォルトの名無しさん
09/02/28 22:25:08
何故 C++ で書かれたバージョン管理システムが普及しないのかを考えたほうが
いいのかもしれない。
monotone くらいか？
450:デフォルトの名無しさん
09/02/28 22:55:05
C++のバージョン管理システムなんて恐ろしくて使えるか
バージョン管理システムのバージョンを管理するシステムが別に必要になる
451:デフォルトの名無しさん
09/02/28 23:30:43
このスレの全ては>>444にまとめられる
452:デフォルトの名無しさん
09/02/28 23:32:41
要は MFC 使ってた奴等が
「C++ 出来ます！！！」
って、大量に蔓延ったのが問題なだけだろ？
453:デフォルトの名無しさん
09/03/01 00:41:52
>>450
SCIMとscim-bridgeを思い出したｗ
454:デフォルトの名無しさん
09/03/01 01:04:37
ゲーム業界でのC++馬鹿はひどい。
どっかの本に書いてあったことを理解せず妄信してまともに動作しないものばかりつくってる。
特に大手の勘違い野郎に多い。
Cのころのほうがまともだった。これはコード量の問題ではない。
455:デフォルトの名無しさん
09/03/01 01:05:30
例えば？
456:デフォルトの名無しさん
09/03/01 01:10:54
組み込み有限メモリでガベージコレクション期待してるとか、
必要でもないポリモーフィズムつかって追跡性落としたりとか、
平気でシングルトンパターン使って自慢げな顔してたりとか。
457:デフォルトの名無しさん
09/03/01 01:15:39
>組み込み有限メモリでガベージコレクション期待してる
それC++馬鹿なの？
458:デフォルトの名無しさん
09/03/01 01:16:17
エンジニア(SE とか マも含む)にとって一番必要な資質
新しい物見かけたら
「ドライバー(ねじ回し)持ってきて！！！」
てな、感じの好奇心
> どっかの本に書いてあったことを理解せず妄信
エンジニアではない
459:デフォルトの名無しさん
09/03/01 01:18:04
>>458
まあほとんどエンジニアなんていないってことだな。
本に書いてあることが正しくて現実を理解しようとしない。
460:デフォルトの名無しさん
09/03/01 01:26:17
その前に本すら読まない奴はエンジニア以下だけどね＾＾
461:デフォルトの名無しさん
09/03/01 01:29:10
達人プログラマーには技術書とそうでない本を月に一冊くらいずつ読めみたいなこと書いてたな。
自分の技術に投資し、自分の畑以外の知見を広げる努力ができなければエンジニアではいられない、とね。
462:デフォルトの名無しさん
09/03/01 01:30:15
愚者は経験に学び、賢者は歴史に学ぶ
経験＝ドライバー(ねじ回し)
歴史＝どっかの本
463:デフォルトの名無しさん
09/03/01 01:33:02
頭でっかちで自分では何も出来ないやつに人気のC++
464:デフォルトの名無しさん
09/03/01 01:34:23
>>463
ちっちぇえなお前の頭ｗｗ
465:デフォルトの名無しさん
09/03/01 01:34:28
技術はプライベートで検証してから導入してください。
おまえのオナニーでデスマとかありえん。
466:デフォルトの名無しさん
09/03/01 01:35:25
どっかの本を妄信している人間を「それは妄信だ」と断じるなら
少なくともその「どっかの本」くらいは読んでいて当然だわな
そうでなく他人に妄信だというなら
おまえ自身が妄信しているのだと
467:デフォルトの名無しさん
09/03/01 01:35:46
頭小さいけどモノつくれちゃうから収入多くて困っちゃう。
468:デフォルトの名無しさん
09/03/01 01:36:45
俺は難しい本を読んでる！とか思ってるやつとかホント使えん。
普通はパラパラって目を通せばその本の価値くらいわかる。
469:デフォルトの名無しさん
09/03/01 01:37:51
学びて思わざれば・・・じゃないが
本で学び、己で考え、経験して確かめる。
何事も中庸の徳だ。
本を読まない奴はエンジニアじゃないし
本を読むばかりで自分で考えようとしない奴もエンジニアじゃない。
470:デフォルトの名無しさん
09/03/01 01:40:21
本を妄信するにせよ、経験を妄信するにせよ
とりあえず、現場ではビッグマウスはやめて心にしまっておけといいたい。
特に若いなら。
471:デフォルトの名無しさん
09/03/01 01:40:25
>>462
中がどうなっているか知ろうとする好奇心が必要なのであって
その好奇心すらない奴は
「経験からも歴史からも何かを得ようとはしない」
と言ってると思うんだが
472:デフォルトの名無しさん
09/03/01 01:42:30
お前らよっぽど本読みたくないんだなｗ
せいぜい「経験」とやらを積んで、俺の職場には来ないでくれ。
473:デフォルトの名無しさん
09/03/01 01:42:36
>>468
よし、お前には孔子の名言をプレゼントだ。
学びて時にこれを習う､亦た説ばしからずや。
もちろん、お前は孔子より偉いに違いない。
474:デフォルトの名無しさん
09/03/01 01:43:23
やっぱC++信者はおかしいわ
475:デフォルトの名無しさん
09/03/01 01:45:20
Linuaは「C++プログラマはウンコ」って言ってるけど
どう考えても奴の文章からは本をいっぱい読んでるように見えるぞ。ん？
476:デフォルトの名無しさん
09/03/01 01:47:23
>>471
そういうことだね。知的好奇心ないやつはエンジニアには向いてない。
知りたいことがあるから本を読む。
本を読んで疑問に感じたことを確かめずにはいられない。
477:デフォルトの名無しさん
09/03/01 01:50:52
だんだん派遣が夢を語るスレになってきたな
こんなところで御託を並べる時間があったら、本読んで指動かしてプログラミングしろよｗ
478:デフォルトの名無しさん
09/03/01 01:53:27
>>477
> 本読んで指動かして
本の内容を理解してないんだったら意味がないわけだが
479:デフォルトの名無しさん
09/03/01 01:57:59
まぁ、何をどういおうと、本を読まないことのいいわけはできない。
480:デフォルトの名無しさん
09/03/01 01:58:57
>>478
その通りだよ
でも、上の方でねじ回し使えとか、経験が云々とか抜かしてる奴がいるからさ
そいつらの言う通りなら、そいつら自身が先ず指動かせよってことで
481:デフォルトの名無しさん
09/03/01 02:16:57
>>480
>>454 が
> どっかの本に書いてあったことを理解せず妄信してまともに動作しないものばかりつくってる。
言ってることが発端なんだから本を読めの指摘はおかしい
本に書いてあることを理解しようとする好奇心は必要
つか、ねじ回しにしたって好奇心が必要って意味での＊極端な＊例だと思うぞ
482:デフォルトの名無しさん
09/03/01 02:21:19
>>481
だから、他人に本を読めだの、ねじ回せだの言ってる奴に、まず自分からやれと言ってるだけだ。
483:デフォルトの名無しさん
09/03/01 02:28:31
>>482 彼らは自分からやってるかも知れないじゃないか？
484:デフォルトの名無しさん
09/03/01 02:37:29
私的感情や政治的理由で「決めつけ」する奴が、
エンジニアに必要な、探究心などをの素質を
備えていると思う?
485:デフォルトの名無しさん
09/03/01 02:51:10
>>482
あぁ、その点は大丈夫。少なくとも本に関しては好きだからどっちゃり読む。
486:デフォルトの名無しさん
09/03/01 02:51:51
>>484
ねじ回しの方は >>481 で指摘した部分に対して
好奇心(言い換えれば探求心?)すら持てないような
奴はエンジニアたる資質がないと言ってるだけじゃない？
正論だと思うけどな………
本の方は末端反射で的外れなことを言ってるだけだから
それでいいだろうけどさ
487:デフォルトの名無しさん
09/03/01 02:59:27
本に関してはｗ好きだからｗｗｗ
488:デフォルトの名無しさん
09/03/01 03:00:15
あれ？もしかして、本嫌いなのに仕方ないから読んでる人？
かわいそうに･･･勉強するのつらいでしょ、それじゃあ。
489:デフォルトの名無しさん
09/03/01 03:01:54
俺も本好きで読んでるな。
好奇心とか特に考えず、活字がないとものたりないっつーか。
俺の周りでは月2,3万本代使うのが普通の連中しかいない。
490:デフォルトの名無しさん
09/03/01 03:05:16
まだ本を読まないこと正当化しようとする奴がいるのか？ｗ
491:デフォルトの名無しさん
09/03/01 03:09:25
このスレは本を読まないクソだらけ、と。^^
492:デフォルトの名無しさん
09/03/01 08:43:50
どの本といわず、ただ本を読め、ってナンセンスだろ
矢沢なんとかの糞本でも何かプラスになるって言うのか？
493:デフォルトの名無しさん
09/03/01 10:51:45
つうか、深夜まで2chやってるやつが本よめとか馬鹿みたい。
その時間にお前が本嫁よ。
本読みながらやってるとしたら、集中力なさすぎ。
494:デフォルトの名無しさん
09/03/01 11:07:13
本読め、本読めと２ちゃんねるに書き込んで、今日も本を読まずに1日終える
こんな生活が早3年
いつになったら俺はソフトを作れるのだろう
そうだ、本を読んで、技術に興味を持てばできるはずだ
２ちゃんねるのみんなにもこのことを伝えてやろう
（上へ戻る）
495:デフォルトの名無しさん
09/03/01 11:14:32
お前ら本読んで、技術に興味持てよ。
俺は本が好きだから毎日本読もうと思ってるから、明日から読むよ。
技術も大事だから、プログラミングは明後日からだ。
じゃあ、明日に備えて今日は寝るか。
（上へ戻る）
496:デフォルトの名無しさん
09/03/01 11:17:06
とりあえず2chブラウザとGUIのブラウザをアンインストールすることから始めないとな
497:デフォルトの名無しさん
09/03/02 00:23:19
なんだ、２ちゃんねるに書き込む人は本を読まない人なのか？
一服の清涼剤にここで毒を吐くくらいいいじゃないか
もちろんほかの時間は本読んでるよ
今日読んだ本はExceptional C++の項目16～24まで
え？それしか読んでないの？
はっはっは･･･最近疲れが溜まってて
498:デフォルトの名無しさん
09/03/02 01:46:41
＞平気でシングルトンパターン使って自慢げな顔してたりとか。
いろいろオレに当てはまってる気がするんだが、シングルトンパターンが非常に危険で使いどころが
難しいというなら具体的に指摘してもらえるとありがたいが、こんなスレじゃ無理かｗ
ゲームみたいな組み込み系に近い開発なら普通に有用だと思うんだが。
Ｃでコード内にstaticで保持したワークで処理を書いたほうがより無難といいたいんだろうか。
初期化コードや終了コードの呼び出しの手間だけでもシングルトンのがマシだと思うけど。
499:デフォルトの名無しさん
09/03/02 01:58:15
シングルトンが正しく動くかどうかはメモリモデルに強く依存すること
シングルトンクラスが複数あると大抵ろくなことにならないということ
マルチスレッドとシングルトンの相性は最悪だということ
この辺をちゃんと理解してるなら使ってもいいと思うよ
500:デフォルトの名無しさん
09/03/02 01:59:50
シングルトンは羊の皮をかぶったグローバル変数だってサッターが書いてた。
501:デフォルトの名無しさん
09/03/02 02:01:05
あ、ちなみに僕はシングルトンパターンよくわからんです。今勉強中ですが。