5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++ってなんであんなに肥大化しちゃったの?

1 :デフォルトの名無しさん:2008/08/28(木) 14:48:15
仕様が大きすぎるくせに、
実用的なライブラリが未整備。

なんかいらいらしない?
こんなこともできないくせに、
なんでこんな仕様ばっかり作るんだよって。
C++ってなんであんなに肥大化しちゃったの?
名前: 仕様書無しさん
E-mail:
内容:
仕様が大きすぎるくせに、
実用的なライブラリが未整備。

なんかいらいらしない?
こんなこともできないくせに、
なんでこんな仕様ばっかり作るんだよって。

C++はなんでもできます。でもなんにもできてないので
つくってね。的な。

2 :デフォルトの名無しさん:2008/08/28(木) 14:49:56
C++0xに期待っ(決めっ!)

3 :デフォルトの名無しさん:2008/08/28(木) 14:51:00
あぁ。なんか変なコピペが入っちゃったw

4 :デフォルトの名無しさん:2008/08/28(木) 15:01:31
wikipediaのC++0xのページ読んで
吐き気がしてきたw

最近、実践用の言語と勉強用の言語の違いが
わかってきたな。勉強用言語って言語仕様の説明に
内部実装の説明が頻繁に出てくるんだよ。

C++というPerlといい。

5 :デフォルトの名無しさん:2008/08/28(木) 16:40:39
必要とされるものを追加した結果だろ。
未踏叩き厨によればw

6 :デフォルトの名無しさん:2008/08/28(木) 21:52:09
読んだことないならC++の設計と進化をぜひ。
そういう仕様になった理由がいろいろ書いてあって、同情できる。
だからと言って、C++が良くなるわけではないけれど。

7 :デフォルトの名無しさん:2008/08/28(木) 21:55:36
Unix原典とかねw
役には立たないけど怒りを抑える効果はある

8 :デフォルトの名無しさん:2008/08/29(金) 06:07:18
MS-DOSのTurbo C++ 3.0のころが
一番素直だった。

あるのはクラスと継承とカプセル化程度。
例外はない。STLはない。当然Boostなんてものもない。
きわめてシンプルなオブジェクト指向言語だった。

9 :デフォルトの名無しさん:2008/08/29(金) 08:34:48
C++が無かったら他の言語のコンパイラやインタプリタの作成も不可能になる

10 :デフォルトの名無しさん:2008/08/29(金) 09:33:50
>>9
Cがあるって言い返されちゃう。

11 :デフォルトの名無しさん:2008/08/29(金) 10:17:32
>>4
C++は勉強用の言語じゃない。超実務用。職人用の道具みたいなもん。
Stroustrup氏がはっきりそう言い切ってる。

12 :デフォルトの名無しさん:2008/08/29(金) 13:15:28
C++が無かったらWindowsも無くなっちゃうな。

13 :デフォルトの名無しさん:2008/08/29(金) 21:07:39
巨大なクラスライブラリがくっついてくるJavaとかC#に比べると
むしろ機能が足りなさすぎるんだが。
この程度でどこが肥大化って感じるんだ?

14 :デフォルトの名無しさん:2008/08/29(金) 22:54:11
そしてJavaもC#も結局C++で書かれてるんだよね。

15 :デフォルトの名無しさん:2008/08/31(日) 03:20:29
まともな C++ の参考書の厚さは異常。
逆に言うと、薄い参考書は当てにならない。

16 :デフォルトの名無しさん:2008/09/08(月) 06:16:18
コーヒーブレーク
http://www.youtube.com/v/8GaivisdRqo, 01:33,[KORG DS-10]はじめてのシンセサイザー第1日目「PITCH(ピッチ)」
http://www.youtube.com/v/dmmriw96UHU, 03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」
http://www.youtube.com/v/uy--pllBniQ, 03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」(修整版)
http://www.youtube.com/v/3nowLPRgoTI, 02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」
http://www.youtube.com/v/pANHFXO2Ll0, 02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」(修整版)
http://www.youtube.com/v/ldtIbmQvzyU, 03:43,[KORG DS-10]はじめてのシンセサイザー第4日目「EG(エンベロープジェネレータ)」
http://www.youtube.com/v/ofG_DTCp434, 04:27,[KORG DS-10]はじめてのシンセサイザー第5日目「EGエピソード2」
http://www.youtube.com/v/atpRE1xmdS8, 07:09,[KORG DS-10]はじめてのシンセサイザー第6日目「VCA」
http://www.youtube.com/v/Znn0_DyAmt4, 03:58,[KORG DS-10]はじめてじゃないシンセサイザー第1日目「PATCH(パッチ)」
http://www.youtube.com/v/q-Uu8_rU2XE, 04:24,[KORG DS-10]はじめてじゃないシンセサイザー第2日目「PATCH その2」
http://www.youtube.com/v/2bJYmIDWrqY, 05:16,[KORG DS-10]はじめてのシーケンサー
http://www.youtube.com/v/Usjy626gQYQ, 05:21,[KORG DS-10]はじめてのシーケンサー(修正版)


17 :デフォルトの名無しさん:2008/09/08(月) 06:19:17
修正コーヒーブレーク
http://www.youtube.com/v/8GaivisdRqo ,01:33,[KORG DS-10]はじめてのシンセサイザー第1日目「PITCH(ピッチ)」
http://www.youtube.com/v/dmmriw96UHU ,03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」
http://www.youtube.com/v/uy--pllBniQ ,03:02,[KORG DS-10]はじめてのシンセサイザー第2日目「VCO」(修整版)
http://www.youtube.com/v/3nowLPRgoTI ,02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」
http://www.youtube.com/v/pANHFXO2Ll0 ,02:23,[KORG DS-10]はじめてのシンセサイザー第3日目「VCF」(修整版)
http://www.youtube.com/v/ldtIbmQvzyU ,03:43,[KORG DS-10]はじめてのシンセサイザー第4日目「EG(エンベロープジェネレータ)」
http://www.youtube.com/v/ofG_DTCp434 ,04:27,[KORG DS-10]はじめてのシンセサイザー第5日目「EGエピソード2」
http://www.youtube.com/v/atpRE1xmdS8 ,07:09,[KORG DS-10]はじめてのシンセサイザー第6日目「VCA」
http://www.youtube.com/v/Znn0_DyAmt4 ,03:58,[KORG DS-10]はじめてじゃないシンセサイザー第1日目「PATCH(パッチ)」
http://www.youtube.com/v/q-Uu8_rU2XE ,04:24,[KORG DS-10]はじめてじゃないシンセサイザー第2日目「PATCH その2」
http://www.youtube.com/v/2bJYmIDWrqY ,05:16,[KORG DS-10]はじめてのシーケンサー
http://www.youtube.com/v/Usjy626gQYQ ,05:21,[KORG DS-10]はじめてのシーケンサー(修正版)


18 :デフォルトの名無しさん:2008/09/08(月) 09:29:21
>実用的なライブラリが未整備。

独自仕様で90%のパソコンで動くライブラリと、その後から出来た
標準規格で誰も使いたくないクソ設計のライブラリがある。

19 :デフォルトの名無しさん:2008/09/08(月) 11:28:58
>>18
実用的なライブラリが未整備って事じゃん

20 :デフォルトの名無しさん:2008/09/08(月) 15:07:06
でも C++ を使うのは面白いよー。
BASIC から C 飛ばしていきなり C++ に行ったけど
こんな面白い言語は他にないよー。ひゃっはー。

21 :デフォルトの名無しさん:2008/09/08(月) 17:34:03
boostのmplやマクロを多用して何言語がよくわからない事をするのが楽しそうですね


22 :デフォルトの名無しさん:2008/09/08(月) 21:43:19
C++の実用ライブラリなんていくらでもあるじゃん。
たんに知らないだけだろ。


23 :デフォルトの名無しさん:2008/09/09(火) 11:31:48
javaだのC#みたく標準ライブラリじゃなきゃわかりません><
てことだろ。

24 :デフォルトの名無しさん:2008/09/09(火) 13:40:20
javaもGUIは標準じゃないだろ。いや、標準じゃないものを使うのが当たり前になっているのかも知らんが。

25 :デフォルトの名無しさん:2008/09/09(火) 14:22:15
AWTって標準じゃないの?

26 :デフォルトの名無しさん:2008/09/09(火) 16:59:15
iostreamの気持ち悪さは以上

27 :デフォルトの名無しさん:2008/09/09(火) 18:57:54
>>22
実用的なライブラリが未整備って事じゃん

28 :デフォルトの名無しさん:2008/09/09(火) 19:06:29
例えば、どんなライブラリが欲しいのかしら?

29 :デフォルトの名無しさん:2008/09/09(火) 19:20:22
メモリリークせず、バッファオーバーランせず、スレッドセーフで、ドキュメントが充実していて
3ステップ以内で大抵のやりたい事ができて、高速で、導入の手間が掛からず
移植性に優れていて、十分に枯れている

そんな実用的なライブラリが欲しいです

30 :デフォルトの名無しさん:2008/09/09(火) 19:24:20
スレッドセーフじゃないのはもうあきらめるしか。
C#でどうですか?

31 :デフォルトの名無しさん:2008/09/09(火) 20:24:54
しーぷらぷらしーえるあい

32 :デフォルトの名無しさん:2008/09/09(火) 20:29:29
>>26
あれでも、昔の仕様よりゃかなりマシになってんだぞw

33 :デフォルトの名無しさん:2008/09/09(火) 20:54:55
iostreamはC++の"入門書"で真っ先に出てくるのが
今思い返すとウザかったなぁ・・・・。
<<演算子のオーバーロードとか、「C++自体がそういう文法」だと錯覚させられた。

34 :デフォルトの名無しさん:2008/09/09(火) 22:12:18
C#なんかは言語よりもランタイムのリフレクションやコード動的生成の機能に頼る方向だよね

35 :デフォルトの名無しさん:2008/09/10(水) 17:26:47
びよ〜んすとらうすとらっぷ

36 :デフォルトの名無しさん:2008/09/10(水) 17:55:18
>>34
だってJavaモドキだもん

37 :デフォルトの名無しさん:2008/09/10(水) 19:01:35
>>29
ライブラリの範疇超えた要求だしなぁ。

38 :デフォルトの名無しさん:2008/09/10(水) 19:46:56
>>37の定義するライブラリの範疇って何よ

39 :デフォルトの名無しさん:2008/09/13(土) 11:37:20
クラスとSTLの相性の悪さが・・・

クラスの中でSTLを使うってだけならいいんだが、
設計そのものに適用しようとするともうぐちゃぐちゃ


40 :デフォルトの名無しさん:2008/09/13(土) 11:57:25
んなことねーべ
STLの根幹であるコンセプトってのはオブジェクト指向の根底にもあるもんだし

41 :デフォルトの名無しさん:2008/09/13(土) 12:20:50
>>39
あんたがSTLを使い慣れてないだけ

42 :デフォルトの名無しさん:2008/09/13(土) 17:59:59
信者がこんなんだから進歩しないのよ

43 :デフォルトの名無しさん:2008/09/13(土) 18:28:32
で、C++は難しいからPHPでも使うかって?

44 :デフォルトの名無しさん:2008/09/13(土) 18:35:32
>>42
違う
原因は互換性っていう過去の柵が8割以上を占めてると思う

45 :デフォルトの名無しさん:2008/09/13(土) 19:26:18
互換性ない俺様言語作るのは簡単だからね

46 :デフォルトの名無しさん:2008/09/13(土) 19:34:01
D言語にとって変わられればいいじゃん。
とか思ってたけどD言語迷走しすぎ。

47 :デフォルトの名無しさん:2008/09/13(土) 20:13:12
Cと互換性のない言語はかわりにはならんし別物になっちゃうんだよなあ。

48 :デフォルトの名無しさん:2008/09/13(土) 20:15:26
Objective-Cの方が良かったんだけどね

49 :デフォルトの名無しさん:2008/09/13(土) 21:31:12
STLってゆうか、テンプレートなんだけど、
テンプレート化したクラスにおいて、別の種類の柔軟性を持たせたくなって仮想関数を
作りたくなるときってないですか? それって無理ですよね?
そんなこと思う事自体が何か間違ってるんでしょうか。

50 :デフォルトの名無しさん:2008/09/13(土) 22:18:14
>>49
クラステンプレートに仮想関数を持たせることはできるよ。
メンバテンプレートで仮想関数は無理だけど。

51 :デフォルトの名無しさん:2008/09/14(日) 10:42:46
世の中の天才PGみてるとC++なんて使わずC使ってるからなぁ

52 :デフォルトの名無しさん:2008/09/14(日) 10:46:01
天才だからCとかアセンブラで十分なんだよ
その人達みたいにCを使いこなすよりはC++をそれなりに使えるようになる方がまだ簡単

53 :デフォルトの名無しさん:2008/09/14(日) 11:28:46
天才は1人でシステム開発するでしょ。だからCで十分なんだよ。

54 :デフォルトの名無しさん:2008/09/14(日) 11:55:23
少人数の開発に向いてるのはLisp

55 :デフォルトの名無しさん:2008/09/14(日) 12:13:14
ほとんどの場合、Cでいいよね
C++とかJavaとかって、無駄にクラスを作ったり無駄にソースコードを
増やして、開発量水増しするために使うもんだと思ってる。

56 :デフォルトの名無しさん:2008/09/14(日) 12:21:26
本気で言ってるのかマジレスなのか非常に気になるが・・・・
オブジェクト指向の言語の必要性を感じてないんか?

それからC++はマルチパラダイム言語と呼ばれるように
非常に懐の広い言語なんだが

57 :デフォルトの名無しさん:2008/09/14(日) 12:34:59
tmpによる静的モデル検証とか使い熟せれば便利だと思う
言語内DSLなんていまじゃ別に奇なものでないしね
あと名前空間とか激しく便利だね、XXX_YYY_ZZZとか書かなくてすむし

でもSTL, boost, TMPとか使わずにC++使うぐらいならC99の方が100倍マシだ

58 :デフォルトの名無しさん:2008/09/14(日) 17:29:57
そもそもC++が幅利かせてるのってwindowsくらいだろ。
UNIXの世界じゃたんなる一選択肢的な感じだし。

59 :デフォルトの名無しさん:2008/09/14(日) 17:37:00
>>56
単にオブジェクト指向っぽくすることだけが目的になってない?
なんのためのオブジェクト指向か分ってる?

60 :デフォルトの名無しさん:2008/09/14(日) 17:41:46
マルチパラダイムと称して
いきあたりばったりに機能拡張した感が否めない

61 :デフォルトの名無しさん:2008/09/14(日) 18:49:18
>>56
C++は書く人がOOPを意識して書けばOOPになるってだけで
実際には>>55のような工数の水増しのネタにされているんだろうなぁ

62 :デフォルトの名無しさん:2008/09/14(日) 19:27:14
なんにでも使えるものはなんの役にも立たないってやつ?

63 :デフォルトの名無しさん:2008/09/14(日) 19:28:35
Javaほど急速じゃないけどCOBOL化が着々と進んでる気がする。

64 :デフォルトの名無しさん:2008/09/14(日) 20:17:42
むしろC++がノロノロと次世代の仕様を作成している間にJavaがここまで肥えるとは思わなかった

65 :デフォルトの名無しさん:2008/09/14(日) 20:43:25
まぁあんだけ群がればピザりまくるに決まってる

66 :デフォルトの名無しさん:2008/09/14(日) 21:47:41
>>62
その状態になっていると思う

67 :デフォルトの名無しさん:2008/09/14(日) 22:02:54
塩は料理から凍結防止ガラス作りまでなんにでも使えるよ。

68 :デフォルトの名無しさん:2008/09/14(日) 22:34:49
Objective-C > C++

69 :デフォルトの名無しさん:2008/09/14(日) 22:37:32
まっかさんはどっかいってね


70 :デフォルトの名無しさん:2008/09/14(日) 22:50:00
オブジェクト指向度マップ

<--- 構造化 オブジェクト指向 --->
C C++ Java C# OC Smalltalk

71 :デフォルトの名無しさん:2008/09/14(日) 22:59:56
スモールトークに需要あるのー

72 :デフォルトの名無しさん:2008/09/14(日) 23:39:00
えいふぇるはどの辺に位置するの?

73 :デフォルトの名無しさん:2008/09/15(月) 00:00:54
実際に Smalltalk に需要があるかどうかは関係なく、
・実行時にメッセージスロットを検索に行く
言語の代表として、歴史的な経緯から使われているに過ぎないのだろう。
Self とか Lua とか JavaScript でも文脈としては問題ないが、先輩に応分の敬意を払わないと非難を受けることだろう。
表面の文法の問題ではないということね。

74 :デフォルトの名無しさん:2008/09/15(月) 00:30:00
>>69
Objective-C >>>>> C++

75 :デフォルトの名無しさん:2008/09/15(月) 01:05:26
すごいね

76 :デフォルトの名無しさん:2008/09/15(月) 01:36:54
初心者向け度って意味ね

77 :デフォルトの名無しさん:2008/09/15(月) 06:21:16
C++0xになったらそろそろ標準の文字列クラスぐらい出てきますよね。

78 :デフォルトの名無しさん:2008/09/15(月) 07:38:39
完全なコンパイル言語でオブジェクト指向やろうとするとC++が限度ってこと。
OCなんてC+オブジェクト指向インタプリタだし。

79 :デフォルトの名無しさん:2008/09/15(月) 11:53:25
>>77
相変わらずstd::basic_stringです。

80 :デフォルトの名無しさん:2008/09/15(月) 13:37:13
>>78
それに加えて C とある程度の互換を持たせるという縛りもきつ過ぎる

81 :デフォルトの名無しさん:2008/09/15(月) 17:12:29
そもそもSTL理念に必要最低限って書いてあったけど。
JAVAやドトネト並みの網羅されたクラスライブラリがあるだけでぜんぜん違うのに

82 :デフォルトの名無しさん:2008/09/16(火) 21:41:32
でもでかいランタイムが必要だと選択肢から外れちゃうよ

83 :デフォルトの名無しさん:2008/09/17(水) 21:43:17
>>82
それは人それぞれなのでは?

84 :デフォルトの名無しさん:2008/09/17(水) 22:16:09
>>83
当然そうだよ
ターゲットの環境や用途等にもよるし

85 :デフォルトの名無しさん:2008/09/18(木) 00:18:59
>>82が結局何を言いたいのかが分からない

86 :デフォルトの名無しさん:2008/09/18(木) 04:11:14
そりゃそのライブラリのために30MBのDLLが必要だったら困るじゃんって話でしょ。
再配布のライセンスとか、インストールが必要なのかとか他のアプリに影響与えないか
とかも重要だし。

87 :デフォルトの名無しさん:2008/09/18(木) 07:50:55
巨大なライブラリがあればもっと可能性が広がるのにって言ってる相手に
それは使えない可能性もあるって言ってなんか意味あるの?

88 :デフォルトの名無しさん:2008/09/18(木) 08:07:26
boostも便利なんだけどさ、amazonにSOAPで繋げて商品情報をGUIで一覧表示したいんだけど、
とか思うとまったく機能が足りてないんだよなあ。

89 :デフォルトの名無しさん:2008/09/18(木) 20:07:10
WTLとか、iostream使ったソケットプログラミングとか、
やろうと思えばいろいろ発展できそうなのにいまいちまとまりがない。
それが++

90 :デフォルトの名無しさん:2008/09/18(木) 20:11:50
大きくなると、まとまりがなくなるのは
どんな言語にもある。

91 :デフォルトの名無しさん:2008/09/18(木) 21:37:33
>>87
その大きさが可能性を狭めることもあるって言ってるんでしょ

92 :デフォルトの名無しさん:2008/09/18(木) 23:30:47
>>91
馬鹿なの?

93 :デフォルトの名無しさん:2008/09/18(木) 23:38:26
馬鹿はお触り禁止
放置しましょう

94 :デフォルトの名無しさん:2008/09/18(木) 23:43:34
>>91の何がおかしいかがわからないので教えてください

95 :デフォルトの名無しさん:2008/09/19(金) 00:02:15
>>81からの流れを例えで表すと

>>81 巨大重機(ライブラリ)があればビル建てるときも楽になるのにね
>>82 でもそんな巨大だと民家建てる時に困るじゃん
>>83 そんなの当たり前じゃないの?
>>84 当たり前だよ
>>85 結局>>82はそんな当たり前の事言いたかったの?
>>86 だから>>82は巨大重機じゃ民家建てる時に困るって言ってるんだよ
>>87 だからそんな当たり前の事言って何の意味があるの?
>>91 だから大きいと困る可能性もあるって言ってるんでしょ
>>92 馬鹿なの?

96 :デフォルトの名無しさん:2008/09/19(金) 00:13:32
ああなるほど
言語と一体化したようなライブラリでなければ>>95のような話だね

昔のVBや現在のドットネットを選択肢から外す状況を想定してた

97 :デフォルトの名無しさん:2008/09/19(金) 00:34:44
>>82はクラスライブラリが欲しいって話から
何時の間にか言語仕様上巨大なランタイムが必須ってとこまで飛躍してたのな。
そんなことしたらC++の存在意義が無くなるだけじゃんw

98 :デフォルトの名無しさん:2008/09/19(金) 02:23:31
C/C++だってランタイムは必要だぜ。
ライブラリモジュールを、配布プログラムに必ず含めなければならないとなれば大きいのは困るけど、
基本モジュールは別途インスコしておいて、アプリはそいつ必要に応じてリンクするのがやっぱりベストな気がするな。
OS以外の基本モジュールはNGなんて環境は相当特殊だろうし。

99 :デフォルトの名無しさん:2008/09/19(金) 03:23:43
Vista64bit使ってると.NETのありがたみが分かってくる。
一部のプログラム以外、.NETのほうが便利だし、
わざわざ32bit, 64bitとリリースを分けるまでもなく
VMが適当に最適化を行ってくれる。

C:\Program Files (x86)\フォルダに入ることもない。

100 :デフォルトの名無しさん:2008/09/19(金) 11:31:11
結局C言語と.NETがあれば十分じゃね?
C++はもう休めばいいよ

101 :デフォルトの名無しさん:2008/09/19(金) 11:42:16
携帯とかゲームとか組み込みとか色々あるから
ちっとも十分じゃない

102 :デフォルトの名無しさん:2008/09/19(金) 11:45:58
嫌C++厨必死ww
現実を見ろよ
どこのコンパイラメーカもC++無しでは食っていけない

103 :デフォルトの名無しさん:2008/09/19(金) 14:40:34
必死さで言うと・・・いやなんでもない

104 :デフォルトの名無しさん:2008/09/19(金) 15:22:13
醜いC++がしぶとく生き残る様は丁度アーキテクチャが汚い
x86がしぶとく生き残る様子に似ているかもしれない

105 :デフォルトの名無しさん:2008/09/19(金) 18:03:22
>>81
http://pc11.2ch.net/test/read.cgi/tech/1206447234/

106 :デフォルトの名無しさん:2008/09/19(金) 18:07:47
>>81
つ[D&E]

107 :デフォルトの名無しさん:2008/09/19(金) 18:33:01
D&Eはただのいいわけ本
ページを捲るたびに「ハイハイワロスワロス」って感想しか出てこない

108 :デフォルトの名無しさん:2008/09/19(金) 18:40:48
と言語の一つも設計した事のないカスがほざいております

109 :デフォルトの名無しさん:2008/09/19(金) 18:45:31
OS選ばないのが前提。

110 :デフォルトの名無しさん:2008/09/19(金) 19:02:10
java…

111 :デフォルトの名無しさん:2008/09/19(金) 23:40:26
>>104
C++が醜いですか?
たとえば何が綺麗なの?

確かにx86は汚い
モトローラの68K系とかのアーキテクチャの方がすっきりして綺麗だった
でもほとんどの人が機械語やアセンブラに直接触れない今では
ソフトウェアから見たアーキテクチャの一貫性などの重要度が低くなったのでx86は生き残ったんだ
C++とは状況が違うと思うよ

共通点は、捨てるのが怖いほど既に投資してしまったこと

112 :デフォルトの名無しさん:2008/09/20(土) 01:14:28
x86の機械語体系は確かにグチャグチャだが、ハードウェア
アーキテクチャに限定して話をすれば80386以降は比較的
まともになったと思うよ。

113 :デフォルトの名無しさん:2008/09/20(土) 07:20:22
Alpha最高

114 :デフォルトの名無しさん:2008/09/20(土) 17:39:43
AMD64 はすっきりしたんじゃない?

115 :デフォルトの名無しさん:2008/09/20(土) 18:49:12
AMD(笑)

116 :デフォルトの名無しさん:2008/09/20(土) 21:48:29
C++最大の成功と失敗はCとの互換性だなあ。
あと時代が古いせいでいろんな事情を言語に載せてしまったように思える。

だからDはもうちょっとがんばって安心して使用できるように配慮してほしい。

117 :デフォルトの名無しさん:2008/09/20(土) 21:50:28
ああそれなら心配いらない
D言語なんて「絶対に」マイナーなままで終わるから

118 :デフォルトの名無しさん:2008/09/20(土) 22:08:50
MSは結構力入れて開発してるみたいだし
C#並にはメジャーになるかもよ

119 :デフォルトの名無しさん:2008/09/20(土) 22:10:24
ソースplz
いつの間にDigitalMarsとM$が手を組んだんだ

120 :デフォルトの名無しさん:2008/09/20(土) 22:17:03
昨日路地裏でキスしているところを見たよ!

121 :デフォルトの名無しさん:2008/09/20(土) 22:20:40
M$とTRONの坂村は手を組んだんだがな

122 :デフォルトの名無しさん:2008/09/20(土) 22:21:57
>>120
けしからん。スグにGoogleに削除要請だ!

123 :デフォルトの名無しさん:2008/09/20(土) 22:58:34
>>117
そうなのかな?
C++が肥大化しすぎているし、ネイティブ言語でまともなものが欲しいと言う需要もあるのでは?
今のところオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。

124 :訂正:2008/09/20(土) 22:59:13
>>123
今のところネイティブのオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。

125 :デフォルトの名無しさん:2008/09/20(土) 23:04:10
ま、マイナーが好きな奴には性癖なんだから何も言わんよ
でもC++がこれだけ流通している理由も考えてみてくれ
たまにでいいから

126 :デフォルトの名無しさん:2008/09/20(土) 23:55:58
>>123
マカー乙

127 :デフォルトの名無しさん:2008/09/21(日) 00:06:26
まぁ糞言語である事は揺ぎ無いよね
すでに投資しすぎたとか諸々の事情で選択肢からはずっと外れないんだけどさ

128 :デフォルトの名無しさん:2008/09/21(日) 00:10:43
糞言語ではないだろう
テンプレートなんか後発言語は皆ジェネリックで真似してるし

129 :デフォルトの名無しさん:2008/09/21(日) 00:24:24
どう糞なのかを説明して欲しい

130 :デフォルトの名無しさん:2008/09/21(日) 00:24:44
>>128
部分的に良いところもある壮大な実験言語だったかもね
ただし、どう考えても言語としては糞だと思う

131 :デフォルトの名無しさん:2008/09/21(日) 00:59:49
その糞を説明しないと

132 :デフォルトの名無しさん:2008/09/21(日) 01:01:23
説明できないんだろ
とにかく 糞 と言いたいだけの厨だよ

133 :デフォルトの名無しさん:2008/09/21(日) 01:07:02
>>132
・肥大化した仕様
・C言語との互換性がなくなってしまった
・静的なオブジェクト指向
・マルチパラダイムを言い訳にしているが、いくらでも醜いコードをかけてしまう

134 :デフォルトの名無しさん:2008/09/21(日) 01:12:09
欠点ばっかり挙げてもな
利点も挙げてみろ

なぜ世の中のプログラムの多くがC++で書かれているのか
その理由がわからないのか

135 :デフォルトの名無しさん:2008/09/21(日) 01:16:54
C++を糞だと言うひとは
あるコンポーネントを実装する言語を選ぶ際に様々な言語を多角的に評価した結果
CとC++が残ったというシチュエーションならどっちを選ぶの?

136 :デフォルトの名無しさん:2008/09/21(日) 01:19:05
>>134
>133を裏返したら利点になる

137 :デフォルトの名無しさん:2008/09/21(日) 01:20:52
という事は>>133は単にC++をけなしたいだけの香具師か

138 :デフォルトの名無しさん:2008/09/21(日) 01:34:36
>>135
そこでObjective-Cですよ

139 :デフォルトの名無しさん:2008/09/21(日) 01:39:53
VC以外日陰だろ

140 :デフォルトの名無しさん:2008/09/21(日) 01:55:47
Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ
C++とは守備範囲が違うと思う

っていうかあんなとってつけたような違和感バリバリの言語を薦めておいて
C++を糞だと言ってんのか

141 :デフォルトの名無しさん:2008/09/21(日) 01:56:14
組み込み系ではCが主流だしw

142 :デフォルトの名無しさん:2008/09/21(日) 02:12:51
>>141
コンパイラが少ないからじゃない?

143 :デフォルトの名無しさん:2008/09/21(日) 02:56:05
過剰なC++擁護派はやっぱ馬鹿だなw
C++以外の選択肢が無い状況なんていくらでもあるが、糞言語と言う事実にはなんら影響しない。
Windowsみたいなもんだと言えば理解できるか?

144 :デフォルトの名無しさん:2008/09/21(日) 03:41:16
無い頭使って必死に習得した学習コストを考えると盲目にマンセーするしかないんだろ

145 :デフォルトの名無しさん:2008/09/21(日) 08:28:02
C++/CLIを介さずにC++のネイティブコードを透過的に
C#から使うことができれば、まだ使い道はあると思うけど

146 :デフォルトの名無しさん:2008/09/21(日) 08:56:47
C++ではソースコードが肥大化しすぎる
言語仕様が弱すぎて、動的エラーを起こす一目でバグと分かるコードでもコンパイラが余裕で通す
C++でGUI作ってるのとか見るとC#やjavaを使った方が100倍速く短く作れる事実を知らんのだろうなあと思う

147 :デフォルトの名無しさん:2008/09/21(日) 09:35:20
それで10倍実行速度が遅いと。

148 :デフォルトの名無しさん:2008/09/21(日) 09:39:14
C/C++の弱点って、作られたバイナリの対象となる実行環境が限られるって事だけじゃん
それ以外の弱点っていうのは、ちょっと思いつかないなぁ


149 :デフォルトの名無しさん:2008/09/21(日) 10:13:34
C#とかJavaでロジックを組んでるのとか見るとHaskellやprologを使った方が100倍短かく早く作れる事実を知らんのだろうなあと思う

150 :デフォルトの名無しさん:2008/09/21(日) 10:23:12
でもHaskellやPrologで作ったOSは知らないなあ

151 :デフォルトの名無しさん:2008/09/21(日) 10:32:27
Cのプログラマーが溢れて給料低下だから、
わざとごちゃごちゃしたC++作ったってネタは面白かったw

まぁ、俺はカプセル化だけでもC++の意味はあると思うが。
そもそもプログラムなんて使えるライブラリがあるかどうかで90%は決まる。

152 :デフォルトの名無しさん:2008/09/21(日) 11:13:29
>>140
>Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ

メッセージ送信だけインタプリタになる。
ただし、ランタイムによってメソッドのアドレスがキャッシュされるのでしばらく動かすと高速になる。

>C++とは守備範囲が違うと思う

組込みとかには向いていないかもね
でもiPhoneだと問題なく動いているし、組込みも高度化するとObjective-Cが使えるってことかと

153 :デフォルトの名無しさん:2008/09/21(日) 11:22:20
C++でも仮想関数使えばObjective-Cと同じになるのではないかと

154 :デフォルトの名無しさん:2008/09/21(日) 12:56:21
>>147
100nsが1msになったところでGUIアプリにとっては大部分がどうでもいいんです
何言ってるか分かりますか?

ホットスポットだけDLLで外出しすれば100倍早く作れて体感できない程度しか遅くならないんです
何言ってるか分かりますか?

155 :デフォルトの名無しさん:2008/09/21(日) 13:29:27
>>153
配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの

156 :デフォルトの名無しさん:2008/09/21(日) 13:31:40
>>154
それが問題なんだよ。
プログラムは 8:2 の法則があるのを知ってるだろ。

要するにプログラムの実行時間の大半は2割のコードが
費やしているという事だが、その部分の速度が1/10に
なったらもっさりするだろ。


157 :デフォルトの名無しさん:2008/09/21(日) 13:33:09
言葉だけ書いてもアレなんで実アプリで説明してみると、
例えばLimeWireってあるだろ。あれはJavaアプリだが、
実に動作がもっさりしている。

WinnyやShareと比べものにならない位もっさりしている。

158 :デフォルトの名無しさん:2008/09/21(日) 13:34:56
>>156
何言ってるのか全く分からなかったんですね
残念です

159 :デフォルトの名無しさん:2008/09/21(日) 13:37:14
あ、言っておくと>>146とは別人で、Javaは論外です

160 :デフォルトの名無しさん:2008/09/21(日) 13:40:31
>>158
だからプロファイルを取ってタイムクリティカルな部分だけでも
C/C++で書けって言ってるんだよ。察しが悪いな。

161 :デフォルトの名無しさん:2008/09/21(日) 13:49:12
…それって結局、
> ホットスポットだけDLLで外出しすれば
と同じことだよね。

162 :デフォルトの名無しさん:2008/09/21(日) 13:50:41
まあそうだな

163 :デフォルトの名無しさん:2008/09/21(日) 13:54:06
要するにJavaは動作が遅いって認めてるわけだ
開発は早いけど

WindowsだけならC#使っちゃうな
Linux/UNIXならJava

164 :デフォルトの名無しさん:2008/09/21(日) 15:15:34
自分はC++が割りと好きだけど
あのコンパイルの遅さは糞だと感じる
これで開発効率が落ちてる
実行時の効率とのトレードオフなんだけど、でもなぁ

165 :デフォルトの名無しさん:2008/09/21(日) 15:56:22
precompiled header使える処理系使えばええやん

166 :デフォルトの名無しさん:2008/09/21(日) 16:04:52
パースに時間が掛かってるというよりも
テンプレートによるコンパイル時演算で時間が掛かるのでPCHじゃ解決しない
Boost.Function とか時間掛かるじゃない
Boost.Iterator とかも

167 :デフォルトの名無しさん:2008/09/21(日) 16:59:40
もうすべてHaskellで書いて未来の処理系のおまじないにすべてを託したい。

168 :デフォルトの名無しさん:2008/09/21(日) 17:48:40
C++使いこなせない奴ってかわいそうってとこまで読んだ

169 :デフォルトの名無しさん:2008/09/21(日) 17:54:23
>>155
>配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの

それってユーザー側の影響はないのではないかと?

170 :デフォルトの名無しさん:2008/09/21(日) 18:10:41
>>169
実行時の効率が結構違う

171 :デフォルトの名無しさん:2008/09/21(日) 21:08:41
現実の世界ではCの移植性が最高、次にだいぶ落ちるけどC++、Javaはもっとも移植性が低い

172 :デフォルトの名無しさん:2008/09/21(日) 21:31:48
JAVAってマルチプラットフォームじゃなかったの?

173 :デフォルトの名無しさん:2008/09/21(日) 21:43:40
Javaも動かないものは動かないしな。
原因がプログラムが悪いにしろなんにしろ、ランエニホエアとかを
売りにしてたから、がっかり度が大きい

174 :デフォルトの名無しさん:2008/09/21(日) 21:53:22
>>173
いやいや、Java VMが移植されてない環境では動かないという意味だと思う

175 :デフォルトの名無しさん:2008/09/21(日) 22:59:16
それと現実的な実行スピードとサイズもCが一番優れてるよな

176 :デフォルトの名無しさん:2008/09/21(日) 23:04:31
>>175
結局のところCを完全に越えた言語がないってことだろ
だから、C++,JAVA,C#,Objective-CなどのようなC言語の派生でうろうろしている
DはCの派生言語の整理かつ集大成にしようとしているようだが、
移行するほどの利点がない

177 :デフォルトの名無しさん:2008/09/21(日) 23:58:24
>>173
結局UNIXとWindowsじゃ要求されるものが違いすぎて
そもそも要求の次元からして殆どの分野で同じものじゃ済まされないんだよな
JAVAあほす

178 :デフォルトの名無しさん:2008/09/22(月) 00:00:24
Cの移植性ってWIN32APIとかはどげんすると?

179 :デフォルトの名無しさん:2008/09/22(月) 02:55:49
Objective-CなんてC++と同等に並べんなよ。原住民の言語じゃねーか。
C#もエスペラント語みたいなもんだろ。綺麗だけど流行っちゃいねえ。

180 :デフォルトの名無しさん:2008/09/22(月) 04:53:47
お前の中では8年前で情報が止まってるんだなw

181 :デフォルトの名無しさん:2008/09/22(月) 06:52:46
お前は8年間妄想してたんだな。Objective-Cでパンは食べれたかい?

182 :デフォルトの名無しさん:2008/09/22(月) 07:22:33
いやあのC#の話なんですが

183 :デフォルトの名無しさん:2008/09/22(月) 15:10:11
Objective-Cは神

184 :デフォルトの名無しさん:2008/09/22(月) 21:07:27
一方、ベルギーの音楽ソフトメーカーは日本人を雇った
ttp://www.flstudio.com/documents/flchan.html


185 :デフォルトの名無しさん:2008/09/23(火) 14:08:51
Objective-Cは神

つまり糞の役にも立たない

186 :デフォルトの名無しさん:2008/09/23(火) 18:57:40
例えば C++ のどの機能を削れるの?

187 :デフォルトの名無しさん:2008/09/23(火) 19:30:02
マクロを削ろう。
ストローのおじさんもマクロを削りたいみたいだし。

188 :デフォルトの名無しさん:2008/09/23(火) 21:41:24
全部の機能を削ればいいと思うよ
そうすれば、移植性が最高、実行速度もトップレベル、バイナリサイズも小さい、しかも習得が容易な言語になる

189 :デフォルトの名無しさん:2008/09/23(火) 22:01:52
Cコンパイラの移植性とネイティブの実行効率が欲しいだけなら
Cソースにコンパイルすればいいんですよ
昔のC++、eiffelやsatherのようにね

190 :デフォルトの名無しさん:2008/09/23(火) 22:13:02
昔のC++からCへのトランスレータには例外とかRTTIないでしょ
そのへんちゃんとしてるのある?

191 :デフォルトの名無しさん:2008/09/23(火) 22:40:00
>>190
>>188

192 :デフォルトの名無しさん:2008/09/23(火) 22:51:53
>>188
ばーか

193 :デフォルトの名無しさん:2008/09/23(火) 22:58:18
>>190
eiffelもsatherも例外ぐらい当たり前のようにあるはずだよ

194 :デフォルトの名無しさん:2008/09/23(火) 23:05:07
さらに C 言語から switch 文、for 文のように必要ない機能を削れば移植性が高くて
学習しやすい言語になるよ。

195 :デフォルトの名無しさん:2008/09/23(火) 23:10:01
>>190
例外もRTTIも自前で実装できない人の発言。
例外なんてジャンプテーブルをスタック状に積み重ねるだけだし、RTTIなんてvtableのアドレスをそのまま使えばいいだけ。

196 :デフォルトの名無しさん:2008/09/23(火) 23:12:58
>>194
C言語からswitchとforを削って移植性が高くなるのは、
その仕様の処理系がC言語の処理系より多くの環境にある場合だけだね

197 :デフォルトの名無しさん:2008/09/23(火) 23:30:53
>>196
C言語のサブセットだからすでにC言語の処理系と同じ数の処理系があると考えていい。

198 :デフォルトの名無しさん:2008/09/23(火) 23:32:18
同じ数の処理系なら移植性は同じっていってるんじゃん

199 :デフォルトの名無しさん:2008/09/23(火) 23:46:40
サブセットの方が処理系が多いし、単純な仕様のほうが移植性が高いんじゃないの?

200 :デフォルトの名無しさん:2008/09/23(火) 23:51:04
>>194
つまんね

201 :デフォルトの名無しさん:2008/09/23(火) 23:54:05
現実にそんな処理系があるなら移植性は高いけど
でもC言語からswitchとforを削った処理系がある?無いよね?
だからそのサブセットは普通のCと比較して実際の移植性は同じだってこと
いま世の中に存在しない夢のコンパイラは比較対象にならない

202 :デフォルトの名無しさん:2008/09/24(水) 00:01:14
>195
cfrontと禿はそれが現実的なコストで出来ないって判断したよ
つか、自前で実装って、毎回ターゲットの環境用に書くんだから移植性は最低だよね

203 :デフォルトの名無しさん:2008/09/24(水) 00:02:27
>>194
ifやwhileなどで置き換えができるからいらないっていう主張なら、関数定義と?と末尾再帰だけでOKになってしまうぞ


204 :デフォルトの名無しさん:2008/09/24(水) 00:09:22
>>194
使いにくくなっちゃうけどね

205 :195:2008/09/24(水) 04:17:19
>>202
もっとわかりやすく。D&Eかなんかのページ数でもいい。
または、移植性最悪だからといってポーティングを諦めた処理系があるなら教えてくれ。

206 :デフォルトの名無しさん:2008/09/24(水) 04:51:33
正直、例外は好きじゃない。

207 :デフォルトの名無しさん:2008/09/24(水) 08:42:09
Maybeを使うんですか

208 :デフォルトの名無しさん:2008/09/24(水) 09:01:13
>205
ここまでの流れをまとめると
>188 C言語最高
>189 ならC++からCへのトランスレータを使えばいいんじゃね?
>190 でも例外とかRTTIとかモダンな仕様を満たすトランスレータは無いよね?
>195 例外とRTTIくらい自前で実装しろ、雑魚
>202 禿もトランスレータでは現実的に無理って判断したよ?


209 :デフォルトの名無しさん:2008/09/24(水) 10:15:23
>>195
移植性の話をしてる時に自前で実装すればいいって発言はありえない

210 :デフォルトの名無しさん:2008/09/24(水) 11:41:49
>>205
スタック操作がからんだら移植性が失われるのは当たり前。阿呆か。

211 :デフォルトの名無しさん:2008/09/24(水) 20:23:42
C++は、C言語がそれほど変わらず存在し続ける為の生け贄。UNIXが存在する限りこの連鎖は断ち切れん。

未来永劫C++はC言語の為に拡張され続ける運命にある、..........................たぶん、

212 :デフォルトの名無しさん:2008/09/24(水) 22:36:57
C++信者って195みたいなのばっかりなの?

213 :デフォルトの名無しさん:2008/09/24(水) 22:44:13
C++信者なんていませんよ。
ファンタジーじゃあるまいし。

214 :デフォルトの名無しさん:2008/09/24(水) 23:08:17
195はファンタジーかよ

215 :デフォルトの名無しさん:2008/09/24(水) 23:10:55
C++がファンタジーになる時代はいつですか?

216 :デフォルトの名無しさん:2008/09/24(水) 23:24:31
C++標準化委員会が「新しい機能はなるべく付け加えるな」と
言い続けてこれだからなあ

PGの欲望っていうのはとどまる所を知らない

217 :デフォルトの名無しさん:2008/09/25(木) 01:13:17
C++なんてコンピュータを制御するための設定ファイルですよ。

218 :デフォルトの名無しさん:2008/09/25(木) 02:32:04
C++ってそんなにダメか?

スピードとそれなりの汎用性を必要とする信号処理フィルタなんて書こうと思ったら
「C++ と 部分的にアセンブラ化の組み合わせ」が、今の最適解じゃない?

実験程度ならmatlabやjavaでもいいけど、スピード命ならC/C++に適わない
まあC++でなくても、Cで済むんだけど、規模が大きいときや、
フィルタを組み合わせたいとき、C++の方が記述が楽になる

219 :デフォルトの名無しさん:2008/09/25(木) 04:10:09
++とか一般人に分からない演算子使うのやめて
C 2.0に名前変えるべき

220 :デフォルトの名無しさん:2008/09/25(木) 06:21:41
むしろすべてC++でいいと思う。最近似たような言語が増えて効率悪すぎ。

221 :デフォルトの名無しさん:2008/09/25(木) 08:06:11
配列とポインタは明確に区別するべきであった。
何故一つ余計に&付けるのをケチったんだ。

222 :デフォルトの名無しさん:2008/09/25(木) 09:03:26
>>218
C++がどうしようもなくダメってわけじゃなくて
CとC++を明確に区別して比較したらC言語の方がより良いってことでしょ

223 :デフォルトの名無しさん:2008/09/25(木) 10:03:46
>>221
配列とポインタを同列に扱えるのがC/C++の強み。
嫌なら使うな。

224 :デフォルトの名無しさん:2008/09/25(木) 10:25:46
>>222
>C言語の方がより良い
誰にとって、どういう点で「良い」つってんだお前は。

225 :デフォルトの名無しさん:2008/09/25(木) 10:44:56
188からの流れ読んだら?
移植性とか実行時の効率とか学習コストの点で「良い」んだろ
まあ個人的には速度に関しては有意な差は無いと判断するけどな

226 :デフォルトの名無しさん:2008/09/25(木) 11:12:26
初期コストが低くてもその後ずっと開発コストが高かったら意味ないだろ。
開発コストが低くてもエンドユーザで実行コストが高かったら意味ないだろ。
C++ が最適

227 :デフォルトの名無しさん:2008/09/25(木) 11:19:17
1〜2行目と3行目に関連が無い
これがファンタジーってやつかw

228 :デフォルトの名無しさん:2008/09/25(木) 11:50:19
>>225
>188からの流れ
そっからかよw
強引な言い訳だな。

229 :デフォルトの名無しさん:2008/09/25(木) 11:57:55
ごめんな
言い訳じゃないんだけど>>208にまとめがあったからつい…

230 :デフォルトの名無しさん:2008/09/25(木) 12:25:28
ばかばっか

231 :デフォルトの名無しさん:2008/09/25(木) 12:43:12
>>227
いちいち説明を書かないと関連性が分からない
めんどくさいやつだな

232 :デフォルトの名無しさん:2008/09/25(木) 18:18:26
いや、関連性は無いぞ。
C++が優れていると主張したいならもっと客観的・論理的な視点を持ってくれ。
226の場合はまず、開発コストという、あいまい且つ広範囲な言葉を使うのをやめて、
もっと定量化可能な別のものさしを定義する必要がある。
次にそれを測定し比較、さらに開発コストとそれ以外のメリットデメリットを比較検討、
その結果C++が最適だと主張するなら構わない。
それを行わず「C++最適」の一点張りでは信者は盲目だと思われても仕方が無いな。

233 :デフォルトの名無しさん:2008/09/25(木) 18:19:38
長い。
3文字でまとめてくれ。

234 :デフォルトの名無しさん:2008/09/25(木) 18:23:19
無関連

235 :デフォルトの名無しさん:2008/09/25(木) 18:23:22




236 :デフォルトの名無しさん:2008/09/25(木) 18:44:40




…どうでもいいですが、C++ を More C として使う発想のない人がいますね。

237 :デフォルトの名無しさん:2008/09/25(木) 18:52:53
そんな使い方つまらないから

238 :デフォルトの名無しさん:2008/09/25(木) 18:57:16
BetterじゃなくてMoreなのかよwwww
さすがC++信者、その発想はなかったわwwww

239 :デフォルトの名無しさん:2008/09/25(木) 20:18:14
俺は自分でプログラム書くときは C++
しかし、外部の業者に仕様書出して作ってもらうときは原則C
C++でかかれたひどいプログラムは見るに耐えない

240 :デフォルトの名無しさん:2008/09/25(木) 22:14:12
型チェックに厳しいところだけでも C++ の方が良いと思うが、もしかして C99 で同レベルになってたりする?

241 :デフォルトの名無しさん:2008/09/25(木) 22:47:28
CINTで開発したら、コンパイル頻度へってええぞー。

242 :デフォルトの名無しさん:2008/09/26(金) 00:51:49
少なくともUNIX界では一部のtkが使ってる程度のニッチ言語

243 :デフォルトの名無しさん:2008/09/26(金) 01:00:47
UNIXだとやはりCなのかね

244 :デフォルトの名無しさん:2008/09/26(金) 02:32:28
GNUとかも大体Cだと思う。
プロジェクト管理ツールのsubversionはCでした。

FireFox3は大体C++でした。

245 :デフォルトの名無しさん:2008/09/26(金) 07:57:31
>>242 Be…

246 :デフォルトの名無しさん:2008/09/26(金) 09:54:54
>>240
C99はその辺の仕様は変わってない。
どっちかってーと、便利な方向に拡張されてる印象。
(複合リテラルとか可変引数マクロとか)

247 :デフォルトの名無しさん:2008/09/26(金) 10:34:37
いま全部読みなおしたけど意外と良スレ
ただもうちょっとまともなC++擁護派の意見が欲しい

248 :デフォルトの名無しさん:2008/09/26(金) 11:05:10
Mozillaのドキュメント読むとアレはもはやC++とは呼びたくない代物だ
まあ確かにC++の可搬性は低いと認めざるを得ないな

C99は独自拡張の現状追認(inlineとか)と可搬性向上(int32_tとか)
それとブロック途中で変数宣言が出来るようになった(C++から逆輸入)
あとC99とC++とは互換性がない
(まあ常識的な範囲では大丈夫だし、すぐに仕様を取り込むだろうけど)

249 :デフォルトの名無しさん:2008/09/26(金) 12:16:44
結構Cも変化してきてたんだな。

250 :デフォルトの名無しさん:2008/09/26(金) 13:05:10
C でプログラム書いている人って忍耐強いね。
C++ を覚えてから C でプログラムを書くなんて考えられなくなった。
Ruby を覚えて凄く便利だと思ったけど C++ とは役割が違うので C++
は捨てられません。

251 :デフォルトの名無しさん:2008/09/26(金) 13:23:03
C++とBeOSといえばfragile base class problemだな
ttp://www.st.rim.or.jp/~osada/translation/developers/BNL_articles/Issue79-insights-j.html
など

252 :デフォルトの名無しさん:2008/09/26(金) 15:19:17
OS の API を COM 風のインタフェースにすればよかったのに。

253 :デフォルトの名無しさん:2008/09/27(土) 22:39:54
C++はほかのプロセスにクラスオブジェクトを送ろうとするだけで困難に直面するからなぁ。

254 :デフォルトの名無しさん:2008/09/27(土) 22:52:27
それはアラインメントの問題じゃなくて??
だとするとCで構造体送っても同じだと思うけど。

255 :デフォルトの名無しさん:2008/09/27(土) 23:01:28
vtable付き構造体を別プロセスに送るのは、そもそも無茶ではなかろうか

256 :デフォルトの名無しさん:2008/09/27(土) 23:14:43
一般的な OS だと vtable 付きに関わらず別プロセスに送れないんじゃない?

257 :デフォルトの名無しさん:2008/09/28(日) 02:42:11
>>253はマヌケな指摘!

もちろん、COMやマルチスレッドを使うときC++が多少不便なのは分かるけど
それは言語の文法的な問題というよりは、言語がサポートするレンジの問題

258 :デフォルトの名無しさん:2008/09/28(日) 08:42:31
ガキの時に遊び場だった小山がたくさんあるとこで
台風が過ぎた後、小山が崩れて穴が開いてたんだよ。
石が崩れててその中に懐中電灯もって仲間と入ってった。
そして通路みたいなとこ奥の方へいったら
人形みたいのが並べてあって今度は横のほうに部屋というか
空間があった。
壁に懐中電灯で照らすとなんか落書きというか
絵が描いてあったぜ。
北斗七星はガキの俺でもわかったが
あとは空を舞う女の絵
テーブルみたいなのがその部屋にあって
天井のほうにも絵があったから
その石テーブルに3人で乗っかったら
そのテーブルの台が割れちまった。
痛いと思ったらなんか石と鉄の棒みたいなので
足挟まってた。石をどけると
何か大きな箱の中に入ったみたいで中には
キラキラ光る数珠の玉みたいのとか、鉄の棒、汚れた布切れ
と小さい円盤みたいなものが何枚かあったよ。
俺は面白えと思ってみんなに内諸にしようと約束
して外にでることにした。
俺たちが外に出ようとして元の出口の方にいったら
ゴゴゴゴーとか地鳴りが聞こえて水が突然津波みたいに
俺たちを流した。
その後俺たちは田んぼまで流れてその場所が
どこかわからなくなっちまった。
後で大きくなった時にそこの場所が改めて確認した。
崩れたまま今は草ボーボーになって残ってる。


259 :デフォルトの名無しさん:2008/09/28(日) 20:18:20
MPI使った分散計算とかに使うととたんに困る。
ポリモフィックなことしてたりすると、型情報をつけておくって、
受けた方は型情報に従ってseitch caseなどで羅列した生成ルーチンを選択して・・・てなことになる。
新しい派生型を加える度にcaseを追加しないといけない。
自動的に派生クラスのコンストラクタを実行とかできないからね。

これはなにもプロセス間通信じゃなくても、クラスオブジェクトのデータをいったんファイルにセーブして再度読み込むとかでも同じ問題が起こる。


260 :デフォルトの名無しさん:2008/09/28(日) 21:45:15
だからCで同じことやろうとしても同じ問題が起こるっつーの。
オブジェクトをそのままファイルに保存とかアホかと。
あと型情報でswitchとかやるのは単なる設計ミスか、あるいはテンプレートで回避できる。
自分の不勉強を棚に上げて、口数少なく記述できないことを言語のせいにすんな。

261 :デフォルトの名無しさん:2008/09/28(日) 22:17:27
switch caseを無くせるのがC++の面白いところなんだけどね

262 :デフォルトの名無しさん:2008/09/28(日) 22:32:19
どんな言語でもそりゃswitchの羅列になる。
よその言語だとそうならないようにシリアライズって機構があるだろ。
C++だってBoostとかが作ってはいる。望みどおりのものかどうかは別として。

263 :デフォルトの名無しさん:2008/09/28(日) 23:14:40
仮想関数使ってできるだけswitchとかif elseをなくすのが
C++の方向じゃないのか
禿もそう言ってたろ

264 :デフォルトの名無しさん:2008/09/29(月) 00:04:27
でも最終的には、マシン語でifになるからEじゃんEじゃんEEjump

265 :デフォルトの名無しさん:2008/09/29(月) 00:19:54
x86で大抵のコンパイラは call [eax+table] みたいなコードになるぞ

266 :デフォルトの名無しさん:2008/09/29(月) 13:01:01
仮想関数によるswitch排除は美しいと思うけど
現実的には、あとからの機能追加とかで
ちょっとした分岐が入る場合にgdgdになりがち

267 :デフォルトの名無しさん:2008/09/29(月) 20:23:11
仮想関数をしっかり使うには、結構設計に悩むが、うまくはまるとかなりいいぞ

268 :デフォルトの名無しさん:2008/09/29(月) 21:27:47
オブジェクト指向やデザインパターンのおかげで変更に強く大きなアプリケーションも
作りやすくなったんだよ。GoF のデザインパターンはほとんど仮想関数使ってるよ。

269 :デフォルトの名無しさん:2008/09/29(月) 21:34:01
仮想関数である必要はないよ
テンプレートメソッドやステートやストラテジーパターンなんてジェネリックスでもできる
他は忘れちゃった

270 :デフォルトの名無しさん:2008/09/29(月) 21:39:05
都銀レベルの本当に巨大なシステムは皆COBOLだけどな


271 :デフォルトの名無しさん:2008/09/29(月) 22:12:43
でも、COBOL開発には夢がない。楽しくもない。

272 :デフォルトの名無しさん:2008/09/29(月) 22:13:51
そう言えば禿はC++の設計時に「楽しくプログラミングできる事を目指す」
ような事を言っていたな

273 :デフォルトの名無しさん:2008/09/29(月) 22:15:06
その割りに出来上がったのがこれかよ

274 :デフォルトの名無しさん:2008/09/29(月) 22:35:51
プログラマーから拡張につぐ拡張の要求が押し寄せて
C++標準化委員会が断り続けたが押し切られたものもあって
カオスになっている

275 :デフォルトの名無しさん:2008/09/29(月) 22:44:49
それもまた一興

276 :デフォルトの名無しさん:2008/09/29(月) 22:48:08
一つの言語で何でもやろうとするからこうなる
MultixやPL/Iと同じだな

277 :デフォルトの名無しさん:2008/09/29(月) 22:56:06
まーMFCみたいに我が道路線で行けばそれなりに安定してる言語だけどね

278 :デフォルトの名無しさん:2008/09/29(月) 23:02:55
今日、インストーラのカスタム動作というのをC#で実装してて
初めてドットネットのライブラリを使った
何だあれは!
ほとんど同じ機能を持つ違う名前のクラスが山ほどあるじゃないか
InstallerCollection って何?ただの配列じゃない
InstallContext って何?辞書を一つ持ってるだけじゃない。つまりただの辞書じゃない

あんなのを使う機会が増えていくのは嫌だな
スレと関係なくなっちゃってスマンな

279 :デフォルトの名無しさん:2008/09/29(月) 23:32:41
>>274
それってどの機能のこと?

280 :デフォルトの名無しさん:2008/09/29(月) 23:48:18
演算子のオーバーロード

281 :デフォルトの名無しさん:2008/09/30(火) 00:16:28
>>277
STLより古いしね

282 :デフォルトの名無しさん:2008/09/30(火) 01:31:13
>>281
演算子のオーバーロードって本当は入れたくなかったんだ。
初めて知った。

283 :デフォルトの名無しさん:2008/09/30(火) 03:41:08
>>282
あんな糞気持ち悪いもんマトモな神経持ってたら拒否る

284 :デフォルトの名無しさん:2008/09/30(火) 03:44:02
タイプ量が劇的に減っていいじゃん

285 :デフォルトの名無しさん:2008/09/30(火) 03:57:12
お前のタイプ量が減った分周りの人間が苦労してるだけなんだけど
まぁ、お前はいいんだよね、お前はさ

286 :デフォルトの名無しさん:2008/09/30(火) 03:59:16
D&E読んでみたけど、演算子オーバーロードについては
Dr.Bjarne自身は入れたくなかったわけではないらしいよ。
実装の難しさ(勿論コンパイラの。)やユーザにとっての難解さがあるんじゃないかと
ためらってたが検証したらそうでもなかったので取り入れたと言ってる。
「どんな言語を使ってもわかりにくいコードを書く人はいる。
誤用を恐れるよりは、便利さに目を向けた方がいい」とのこと。

実際、行列とかのクラスで mat1.Multiply(mat2.Multiply(mat3))とかイヤすぎる・・・

287 :デフォルトの名無しさん:2008/09/30(火) 04:00:48
>>285
それはお前の職場環境が悪いだけ。
バカがバカなコード書くのを言語のせいにするなと。

288 :デフォルトの名無しさん:2008/09/30(火) 05:13:46
   _,,....,,_  _人人人人人人人人人人人人人人人人人_
-''":::::::::::::`''>便利さに目を向けた結果が今のC++だよ!! <
ヽ::::::::::::::::::::: ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^^Y^YY^Y^Y^Y^Y^ ̄
 |::::::;ノ´ ̄\:::::::::::\_,. -‐ァ     __   _____   ______
 |::::ノ   ヽ、ヽr-r'"´  (.__    ,´ _,, '-´ ̄ ̄`-ゝ 、_ イ、
_,.!イ_  _,.ヘーァ'二ハ二ヽ、へ,_7   'r ´          ヽ、ン、
::::::rー''7コ-‐'"´    ;  ', `ヽ/`7 ,'==─-      -─==', i
r-'ァ'"´/  /! ハ  ハ  !  iヾ_ノ i イ iゝ、イ人レ/_ルヽイ i |
!イ´ ,' | /__,.!/ V 、!__ハ  ,' ,ゝ レリイi (ヒ_]     ヒ_ン ).| .|、i .||
`!  !/レi' (ヒ_]     ヒ_ン レ'i ノ   !Y!""  ,___,   "" 「 !ノ i |
,'  ノ   !'"    ,___,  "' i .レ'    L.',.   ヽ _ン    L」 ノ| .|
 (  ,ハ    ヽ _ン   人!      | ||ヽ、       ,イ| ||イ| /
,.ヘ,)、  )>,、 _____, ,.イ  ハ    レ ル` ー--─ ´ルレ レ´

289 :デフォルトの名無しさん:2008/09/30(火) 05:20:30
演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ

290 :デフォルトの名無しさん:2008/09/30(火) 05:37:01
なんでそんな入社一年目でも普通に使ってる初歩的機能に熱く議論してんだ?
新入社員がlambdaとmplでばかり書いてしまって困ってますとかなら議論できそうだが。

291 :デフォルトの名無しさん:2008/09/30(火) 05:41:07
なんでC++擁護派っぽいカキコってこんなヌケてるの?
アンチの工作なの?

292 :デフォルトの名無しさん:2008/09/30(火) 09:22:59
C++擁護派って新人もしくは学生でWindows好きそうなイメージがある

293 :デフォルトの名無しさん:2008/09/30(火) 10:54:01
>>289
×演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
○C++ってバカが俺ってSUGEEEEEEするための言語だろ

294 :デフォルトの名無しさん:2008/09/30(火) 11:00:24
G++ごときで挫折したマヌケですね

295 :デフォルトの名無しさん:2008/09/30(火) 12:25:54
演算子オーバーロードは単なる表記の便利さの問題じゃなくて
ダックタイピングの言語では必然と言っていいと思うがな

ダックタイピングでは、アヒルのように鳴くものはアヒルである
だから、整数のように足せるものは+で足せなければならない

実際RubyやPythonでもそれは採用されているし
基本的な道具になっている

C++もテンプレートの世界は一種の静的ダックタイピングだから
演算子オーバーロードは本質的で、それなしでは
組み込み配列やポインタ、関数を
全く同じように扱えるSTLのようなライブラリは作れないし
生まれなかったよ

296 :デフォルトの名無しさん:2008/09/30(火) 12:57:24
文字列の連結が+なのはとても整数のようでは

297 :デフォルトの名無しさん:2008/09/30(火) 13:16:32
文字列の + による結合は自然じゃないか?
演算子オーバーロードのない Java ですら文字列は特別に + を使えるようにしている。

298 :デフォルトの名無しさん:2008/09/30(火) 13:16:44
operatorが難しいとか感じる奴は死んでいいでしょ

299 :デフォルトの名無しさん:2008/09/30(火) 13:53:01
>>298
>operatorが難しいとか感じる奴
誰もそんな話してないんだけど
唐突にどうした?

300 :デフォルトの名無しさん:2008/09/30(火) 13:59:14
>>289あたりのことを指してるんだろうが
演算子オーバーロード否定論者ってJava厨あたりじゃないの
今時C#やPythonやRubyにもあるような機能なんだけど
となりのブドウはすっぱいという奴だろう

301 :デフォルトの名無しさん:2008/09/30(火) 14:33:03
+は普通可換だけど、文字列の連結は可換じゃないよね。

302 :デフォルトの名無しさん:2008/09/30(火) 14:43:12
文字列に+はある意味趣味の問題だろうな

BigNumや複素数、クォータニオン、ベクトル、行列のようなものに
演算子オーバーロードが使えるかどうかはかなり大きな問題だが

303 :デフォルトの名無しさん:2008/09/30(火) 15:56:59
演算子オーバーロードは複素数計算では必須。だから、C++とC#しかない。

304 :デフォルトの名無しさん:2008/09/30(火) 17:11:28
Fortranにもある

305 :デフォルトの名無しさん:2008/09/30(火) 18:20:14
DにもDelphiにもある。

306 :デフォルトの名無しさん:2008/09/30(火) 21:29:08
参照とポインタ、両方ともC++に実装せずに片方だけ実装すれば、よかったかも、

アクセス修飾子は削れない。

例外処理も削れない。

STLは微妙、自分で作った方が使いやすい(気分がする)

あんま削るとこ無いね。


307 :デフォルトの名無しさん:2008/09/30(火) 21:48:07
STLを自作してたら、他人のライブラリと組み合わせるとき悲惨だぜ
自分の作った車輪と他人が作った車輪が乱立しているなんて耐えられない

308 :デフォルトの名無しさん:2008/09/30(火) 21:54:36
>>306
参照とポインタはclassとstructぐらい違うぞ

309 :デフォルトの名無しさん:2008/09/30(火) 21:54:47
>>306
ターゲット環境が貧弱で、constやカスタムアロケータや配置newを使いまくる人?
そういう人は例外も使わなそうな印象があるが

310 :デフォルトの名無しさん:2008/09/30(火) 21:55:26
>>308
> classとstructぐらい
それって大した違いじゃないなw

311 :デフォルトの名無しさん:2008/09/30(火) 21:59:00
>>306
>STLは微妙、自分で作った方が使いやすい(気分がする)
これは狂気の沙汰と言わざるを得ない

312 :デフォルトの名無しさん:2008/09/30(火) 22:00:21
参照に関してはコンパイラ側で
ポインタを用いた内部実装しろと強制されているわけではないが
実質ほとんどのコンパイラは同じにしているだろう

せいぜい関数のインライン展開の場合に変わるぐらいか?

313 :デフォルトの名無しさん:2008/09/30(火) 22:06:37
>>306
アンチC++工作員乙w

314 :デフォルトの名無しさん:2008/09/30(火) 22:17:04
stlは結局必要なものがない
あと基本設計がクソ過ぎる

315 :デフォルトの名無しさん:2008/09/30(火) 22:31:02
とうぞ糞でないものを教えてください

316 :デフォルトの名無しさん:2008/09/30(火) 22:32:42
とうぞ糞?

317 :デフォルトの名無しさん:2008/10/01(水) 01:30:27
>>314 「ただ1つのベースクラスから継承して作っていないとか、どんだけクソ設計なんですか^^」
とかだったら笑う。

318 :デフォルトの名無しさん:2008/10/01(水) 01:38:06
>>317
そんな発想できるお前に笑った

319 :デフォルトの名無しさん:2008/10/01(水) 01:45:42
かゆいとこに手が届かない感じだよ。CStringからstringとかにわざわざダウングレード
するのもどうかと思う。

320 :デフォルトの名無しさん:2008/10/01(水) 01:51:00
CStringのどのあたりが優れてる?


321 :デフォルトの名無しさん:2008/10/01(水) 03:55:39
STLといえば、まずは vector, list, mapじゃないの?
string系はおまけ的なものだから論点が違うよ

322 :デフォルトの名無しさん:2008/10/01(水) 04:03:48
そもそも環境依存のアプリ屋は、C++を積極的に使う必要はないだろ
C#やobject Cと、最新ライブラリをを使う方が効率がいいじゃないか

それに対し、C/C++系は組み込みや科学計算も含む広いレンジを考えてるから
たとえば stringに文字コード変換など気軽に組み込むわけにはいかない

ここには、言語の乱立を嫌がる人もいるが違うと思うな モノには適材適所がある

323 :デフォルトの名無しさん:2008/10/01(水) 05:25:46
vectorはメモリの連続性が信用できないから素直に配列の方がいい
listもリンクリスト程度なら自分で作った方が安心できる
mapは便利だけどクソ遅い

STLは富豪プログラミングできるときにだけ使えて
mapとsetだけが多少とも役に立つ

324 :デフォルトの名無しさん:2008/10/01(水) 05:41:09
メモリが連続している必要があるの?
まあ、連続していないとアクセスは遅くなるけどさ。
気にするほどのものかな

325 :デフォルトの名無しさん:2008/10/01(水) 06:03:04
連続してないならないで別にいい(それがdequeだしな)
信用できないというのが大問題

326 :デフォルトの名無しさん:2008/10/01(水) 07:57:47
vectorで確保するメモリは連続だったでしょ
stringと勘違いしてない?


327 :デフォルトの名無しさん:2008/10/01(水) 08:06:31
http://www.cranehouse.jp/program/vector.html
こんなの発見。
昔のコンパイラだと連続していなくとも標準を名乗れたらしい。

328 :デフォルトの名無しさん:2008/10/01(水) 09:24:58
std::vector 連続 で検索すれば答えは出てくる
当初の規格書に明言されてなかったのは問題だったけど

329 :デフォルトの名無しさん:2008/10/01(水) 10:05:05
言語が効率第一なわりに何でもコピーベースだよな
CVOつっても限界あるし
参照ベース + GCな言語より非効率な面もかなり多いんじゃないか

std::stringは中途半端な存在だと思う
mutableで、しかしバッファの直書き換えはできなくて、
vector<char>に比べて文字列処理において著しく便利というほどでもなく
STL algorithmとの直交性にも欠ける

STLは、C++標準ライブラリの中では一番マシじゃないのか
iostreamだのlocaleだのはどうしようもない

330 :329:2008/10/01(水) 10:31:04
なんだCVOってw
RVOだ、すまん

331 :デフォルトの名無しさん:2008/10/01(水) 10:37:52
カスタム・ヴィークル・オペレーション

332 :デフォルトの名無しさん:2008/10/01(水) 10:48:31
>>322
広いレンジって言っても文字が文字コード想定してないってだめでしょ。
JavaもC#もStringとかStreamはちゃんと変換できるようになってるからみんな
おとなしく使ってるでしょ。

333 :デフォルトの名無しさん:2008/10/01(水) 11:39:18
文字コード変換ってでっかいテーブルが必要だったりするから
組み込みでは難しかったりするんだろう
ライブラリに任せるというのは比較的真っ当なやり方だと思うがね

そもそもC/C++標準ではファイルシステムの存在すら仮定してないし
そういったシステムに依存するような仕様を緩くして
実装可能な範囲を広げようというスタンスなんだろう

334 :デフォルトの名無しさん:2008/10/01(水) 11:47:29
標準にlocaleがあるしcodecvtファセットがエンコード変換することになってるよ

まあ糞だけど

335 :デフォルトの名無しさん:2008/10/01(水) 17:39:52
間違った所を緩めてどうでもいい所を締めるから
COAP(笑)だのvector<bool>(爆)だのみたいな悲劇が生まれるんだよ

336 :デフォルトの名無しさん:2008/10/01(水) 17:46:37
どう考えてもMFCやVCLが実用的

337 :デフォルトの名無しさん:2008/10/01(水) 17:50:15
>> 336
組み込みでMFCやVCLは動きません 役割が違うのに批判されても困るわ

338 :デフォルトの名無しさん:2008/10/01(水) 17:50:47
何度ループしても糞であるという結論にしか至らないC++(笑)

339 :デフォルトの名無しさん:2008/10/01(水) 17:57:34
アホですね(笑)

340 :デフォルトの名無しさん:2008/10/01(水) 17:58:35
組み込みでSTLなんてそれこそ使えるか

341 :デフォルトの名無しさん:2008/10/01(水) 17:59:14
言語の標準ライブラリが特殊環境を想定する必要はない

342 :デフォルトの名無しさん:2008/10/01(水) 18:00:08
いまどきの組み込みはJavaや.NETが普通に動く世界なんだろ

343 :デフォルトの名無しさん:2008/10/01(水) 18:01:08
そんなのはハイエンドか産業用だけです

344 :デフォルトの名無しさん:2008/10/01(水) 18:08:44
Lispで動く炊飯器を見たい

345 :デフォルトの名無しさん:2008/10/01(水) 18:12:53
STLは、単品で使うには粗末だし。
メーカーのライブラリの基盤に採用するには癖が強すぎる。
何より標準ライブラリを名乗っている割に後発なのが痛い。

346 :デフォルトの名無しさん:2008/10/01(水) 18:14:44
もはや組み込み専用マイナー言語に落ち果てているのに
仕様的には肥大化しきってる

ぶっちゃけCでいいじゃん
人生をかけてC++を学んだ様な奴は認められないんだろうけど(笑)

347 :デフォルトの名無しさん:2008/10/01(水) 18:17:22
>>346
主な需要は組み込み、ゲーム、パッケージソフト
てなとこか
でも組み込みはどっちかっつうとCのがまだメインなんじゃないか?
他ではほとんど死んでるな

パッケージも、本当はC++である必要が無い気がするな
.NETやJavaまでいかんでも、リッチなOSを前提にできるんなら
GCぐらいはあってもいいし、ギチギチのzero overhead ruleなんて必要ない

348 :デフォルトの名無しさん:2008/10/01(水) 18:30:51
結論としては、CとC++の中間くらいが一番良さそうだな。
つまり、基本Cみたいな使い方でゴテゴテしたC++の機能は使わなかった俺が正解か。

349 :デフォルトの名無しさん:2008/10/01(水) 18:35:08
C++の素晴らしいところは本物のデストラクタを持ってることだ
リソースの完全な管理という点では今でも右に出る言語はないと思っている

350 :デフォルトの名無しさん:2008/10/01(水) 18:38:23
>>349
そっすねw
自己管理がんばってくださいww

351 :デフォルトの名無しさん:2008/10/01(水) 18:42:36
うんw
実際自己管理を頑張らなきゃならない場合ってのはあって
そういう時だけはC++は本当に役に立つし、なくてはならないんだよ
そういう時だけはな

352 :デフォルトの名無しさん:2008/10/01(水) 18:50:23
Pythonみたいに参照カウントとマーク&スイープ併用してる言語もあるよ

C++でshared_ptr使って参照カウントは出来るが、フツーのGCより効率悪いよね
便利機能一切使わない覚悟でないとC++のコードは速くならないっつか
確実にCより遅くなる
スレッドのことは勿論なにも考えてないからマルチコア時代では先が見えてるしな

353 :デフォルトの名無しさん:2008/10/01(水) 18:51:00
デストラクタならJAVAのほうがマシな実装だと思うぞ

354 :デフォルトの名無しさん:2008/10/01(水) 18:54:28
>>353
廃棄のタイミングを厳密に制御したいんでしょ

Pythonはブロック抜けで参照カウント0になれば廃棄されるし
(当たり前だがデストラクタは定義できるし実行される)
巡回参照でも大丈夫だよ

355 :デフォルトの名無しさん:2008/10/01(水) 18:56:04
>>348
D言語ですね、

でも、現在迷走中。

356 :デフォルトの名無しさん:2008/10/01(水) 18:57:16
Dは最初の狙いは悪くなかったと思うけど
開発者の独りよがりな趣味で終わりそうだね

357 :デフォルトの名無しさん:2008/10/01(水) 19:01:03
>>353
Javaのはデストラクタじゃなくてファイナライザ
ファイナライザは全然役に立たない

358 :デフォルトの名無しさん:2008/10/01(水) 19:07:32
C++/CLI最強説

359 :デフォルトの名無しさん:2008/10/01(水) 19:24:17
>>358
割と本気でそう思ってるんだが誰も同意してくれない

360 :デフォルトの名無しさん:2008/10/01(水) 19:39:17
>>358
C#の方が好きだ。

361 :デフォルトの名無しさん:2008/10/01(水) 19:45:55
C#もデストラクタないんだよな…

362 :デフォルトの名無しさん:2008/10/01(水) 19:47:53
IDisposable

363 :デフォルトの名無しさん:2008/10/01(水) 19:50:47
それデストラクタじゃなくてdelete

364 :デフォルトの名無しさん:2008/10/01(水) 19:52:01
using(Hoge hoge = new Hoge())
{
 //なになに
}

365 :デフォルトの名無しさん:2008/10/01(水) 19:53:40
確かにマルチスレッドとかマルチプロセスに特化した言語は欲しいな。

366 :デフォルトの名無しさん:2008/10/01(水) 19:54:54
うお、そんな書き方出来るのか初めて知った

C#いいな!

367 :デフォルトの名無しさん:2008/10/01(水) 19:58:04
でもC#にはローカル変数とかのfinal宣言子がない…
あればいいのに あれば…

368 :デフォルトの名無しさん:2008/10/01(水) 19:59:38
>>364
同じキーワードをあっちこっちの用途で流用するところはC++譲りみたいだな

369 :デフォルトの名無しさん:2008/10/01(水) 20:00:52
>>364
それ使いたいオブジェクトの数が増えると構文が悲惨よw

370 :デフォルトの名無しさん:2008/10/01(水) 20:01:01
もしかしてJavaもできるの?
C++はdeleteし忘れるからGC最高とか言ってる奴らが
結局finally節にdispose()とかclose()とかunlock()とかチマチマ書いてるのが
とっても滑稽だと思って以来いい印象ないんだけど
出来るなら認識改めないと

371 :デフォルトの名無しさん:2008/10/01(水) 20:05:30
スマポでええヤン

372 :デフォルトの名無しさん:2008/10/01(水) 20:08:51
コンテナに入らないふざけた奴か

373 :デフォルトの名無しさん:2008/10/01(水) 20:10:56
スマポが悪いんじゃないんです
auto_ptrがアホの子なだけなんです
COAPとか使いたがる奴らが悪いんです
許してあげて下さい

374 :デフォルトの名無しさん:2008/10/01(水) 20:17:30
まさに 「痒い所に手が届かない」

375 :デフォルトの名無しさん:2008/10/01(水) 20:18:10
tr1まで標準にリファレンスカウントなスマポ入れなかったってのは、
そもそも標準にスレッドセーフという概念が無いからか?
どっちみちSTLがスレッド?何それ?状態だから関係ねーけどな

ヨボヨボすぎて、もうモダンなOSの主要言語の座はとっくに引退していい仕様だろ
お爺ちゃんをいつまでも無理して使いすぎなんだよ

376 :デフォルトの名無しさん:2008/10/01(水) 20:21:27
0xでようやくスレッドの概念が入って
スレッドローカル変数とかが定義できるようになるらしいけどな

マトモになるのはいつになるやら

377 :デフォルトの名無しさん:2008/10/01(水) 20:26:31
iostreamとか、仕様練る時に変だろこれと誰一人思わなかったのかな。

378 :デフォルトの名無しさん:2008/10/01(水) 20:26:44
え?マトモにする予定なんてあるの?

379 :デフォルトの名無しさん:2008/10/01(水) 20:31:52
>>377
sprintfひとつですむことを
だらだら << 繰り返して書くのが楽しい。┐(´∇`)┌

380 :デフォルトの名無しさん:2008/10/01(水) 20:33:38
>>370
GCが便利なのはいっちいっちコピー先バッファとか
頭の悪いもの引数に用意しなくて済むからだよ。

381 :デフォルトの名無しさん:2008/10/01(水) 20:40:32
shared_ptrとか使って、ただのポインタアクセスをいちいち高価なものに
置き換えたりする必要も無いしな

382 :デフォルトの名無しさん:2008/10/01(水) 20:44:10
GCはshared_ptrなんぞよりよっぽど高価ですが

383 :デフォルトの名無しさん:2008/10/01(水) 20:49:05
>>377
iostreamの凄いところは、初期の仕様を捨ててわざわざ新しくしたのにそれでも糞であるというとこだね。
iostream絡みの昔のコードはどのみち通らないんだから、それなら思い切って捨ててしまえば良かったのに。

384 :デフォルトの名無しさん:2008/10/01(水) 20:54:12
マネージだからメモリリークしないと思っている人。
確かに、プログラムが終了するときにはリークしないでしょう。
けれど例えば、ある操作を繰り返すたびにメモリが解放されずに残ってしまう
ということは有り得ます。Javaでも同様です。
たとえば、ArrayListにStringを追加し続けているようなものです。

385 :デフォルトの名無しさん:2008/10/01(水) 21:01:53
GCは普通に使う分には便利だが
ゲームのオブジェクト管理とかやろうと思うとウザくなる

386 :デフォルトの名無しさん:2008/10/01(水) 21:02:09
>>384
unmanagedでもプログラム終了したらリークはしないでしょう。
何か特別なことしない限り。

387 :デフォルトの名無しさん:2008/10/01(水) 21:07:02
>>358
C++/CLIもコレクションに入れるとデストラクタが無力化する


388 :デフォルトの名無しさん:2008/10/01(水) 21:08:36
まあ、そんなに参照されるのがいやならソフトリファレンスでも使えや

389 :デフォルトの名無しさん:2008/10/01(水) 21:50:39
>>387
msclr::auto_handleは?

390 :デフォルトの名無しさん:2008/10/01(水) 21:53:43
そもそもauto_handle自身のデストラクタが働かないから_

391 :デフォルトの名無しさん:2008/10/01(水) 22:35:54
やっぱりmallocが最高だな。

392 :デフォルトの名無しさん:2008/10/01(水) 23:54:57
aro

393 :デフォルトの名無しさん:2008/10/02(木) 00:39:29
C++0x みたいな継ぎ接ぎはもういいから、新しいプログラミング言語の作成しろ。

394 :デフォルトの名無しさん:2008/10/02(木) 01:43:49
STL を組み込みで使えないという意見があったが、
処理系のデフォルトの operator new とか std::allocator
とかを使わないというだけで、<algorithm> も使うし
自前アロケータでコンテナも使うよ。

395 :デフォルトの名無しさん:2008/10/02(木) 09:16:30
C言語を完全に駆逐するためには
http://pc11.2ch.net/test/read.cgi/tech/1210158702/

396 :デフォルトの名無しさん:2008/10/02(木) 10:58:03
unixの設計のためにCを作ったように、
新しいOSのために、全く新しい言語が生み出されるであろう。

397 :デフォルトの名無しさん:2008/10/02(木) 11:29:35
んなこたぁー、ない。

398 :デフォルトの名無しさん:2008/10/02(木) 18:09:47
Be…

399 :デフォルトの名無しさん:2008/10/02(木) 18:30:28
並列プログラミングが重要視される時代なのでやっぱり新しい言語が必要。

400 :デフォルトの名無しさん:2008/10/02(木) 18:33:23
ConcurrentC

401 :デフォルトの名無しさん:2008/10/02(木) 18:41:36
Nextだろ

402 :デフォルトの名無しさん:2008/10/02(木) 23:07:59
素朴な疑問なんだが
C++がCより開発効率が良いって主張あるよな?
ひとによっては暗黙の了解になってるぽいんだが
それって誰がいつどうやって比べたの?
ソースはあるの?

403 :デフォルトの名無しさん:2008/10/02(木) 23:32:14
鉛筆を一本ずつ数えるのとダースで数える程度の違い
ヘッダファイルの仕様化度が高いともいえるけど
所詮はマクロアセンブラを構文化しただけの言語
いくらでも非効率にも効率的にもできる

404 :デフォルトの名無しさん:2008/10/02(木) 23:34:08
↑に付いては知らんけど、COBOLの方がJavaよりも開発効率がいいなんて言い出すCOBOL脳には成るなよ。

405 :404:2008/10/02(木) 23:36:10
>>402

406 :デフォルトの名無しさん:2008/10/02(木) 23:40:42
>>402
高級言語の中で比較するんならどっちみちC++の生産性は低い
それ以上に再利用のしにくさが致命的
ABIが糞でコンパイル時計算への依存度が高いからな

407 :デフォルトの名無しさん:2008/10/02(木) 23:41:06
一応COBOLは開発効率を重視した言語だ
ただし、プログラマー向けじゃないけどね

408 :デフォルトの名無しさん:2008/10/02(木) 23:46:15
ソースは?脳内?

409 :デフォルトの名無しさん:2008/10/03(金) 00:01:41
個人的には、高級言語の皮を被った低級言語って感じでいいんだけどな。
基本Cでいいんだけど、少しだけ楽したいみたいな。

410 :デフォルトの名無しさん:2008/10/03(金) 00:12:25
ソースもなにも両方でプログラム作れば感覚でわかるだろ。

411 :デフォルトの名無しさん:2008/10/03(金) 01:42:23
CがC++よりいいって・・どうやってWindow表示すんの?MFCとかATLとか使わんの?クラスも使わんの?
CreateWindow(........)とかばっかしてがんばるの?なんなの?ばかなの?

412 :デフォルトの名無しさん:2008/10/03(金) 01:50:29
いい加減、開発の目的や背景を理解できるようになってくれ

413 :デフォルトの名無しさん:2008/10/03(金) 02:06:05
>>411
酷い馬鹿を見た
>>1から1000回読み直せ

414 :デフォルトの名無しさん:2008/10/03(金) 02:17:32
適切な設計をすればCよりは保守性も効率も上がると思うんだけど。
なんか極端なアンチが沸いてるが(俺ももちろんC++が楽だとは言わんが)、
必死に叩いてる奴って、クラスやテンプレートの使い方のセンスが無いor
理解できてない馬鹿ばっかりじゃないの?
単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
機能の使い方が悪い以外に考えられん。

415 :デフォルトの名無しさん:2008/10/03(金) 02:28:59
> 単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
> 機能の使い方が悪い以外に考えられん。

「キッチンシンク」という言葉は知ってるか?
なぜMultixが失敗してUnixが生まれたかを知っていれば
「大きいことはいいことだ」という単純素朴な発想は出てこないはずだ

C++みたいな半端な言語で何でもやろうとするのではなく、もっと高級で
ずっと生産性の高い言語とCを組み合わせるという選択も普通にあるんだが、
それも見えていないようだね

416 :デフォルトの名無しさん:2008/10/03(金) 02:39:29
まぁ、実際を考えると、マルチプラットフォームで使えるちゃんとしたコンパイラがあるかどうかってのもあるなw

417 :デフォルトの名無しさん:2008/10/03(金) 02:49:20
>>414
なるほど、C++の標準の策定者は「理解できてない馬鹿」で「機能の使い方が悪い」
からiostreamとか作っちゃうわけだな

418 :デフォルトの名無しさん:2008/10/03(金) 02:59:05
実用性は無くても、オブジェクト指向言語の可能性を立派にアピールしたよ

419 :デフォルトの名無しさん:2008/10/03(金) 03:01:58
C++をOOの代表であるかのごとくに言ったらOO信者の猛反発喰らうぞw

420 :デフォルトの名無しさん:2008/10/03(金) 03:14:54
C++はOOのOOらしさを極限までそぎ落とし、効率に振り向けた言語だからな

421 :デフォルトの名無しさん:2008/10/03(金) 03:55:47
オブジェクト指向言語の可能性←大間違い
オブジェクト指向の可能性←ギリギリおk

422 :デフォルトの名無しさん:2008/10/03(金) 04:01:16
SimulaとSmalltalkに失礼だな

423 :デフォルトの名無しさん:2008/10/03(金) 04:07:21
実用性皆無の実験言語が一般にアピールはないだろ
影響領域が違いすぎで失礼とかないわ

424 :414:2008/10/03(金) 04:21:43
>もっと高級でずっと生産性の高い言語とCを組み合わせるという
>選択も普通にあるんだが、それも見えていないようだね
なんか偉そうに言ってるけど、C++は実行効率最優先の言語なんですが。
生産効率が良くて、速度やメモリ効率を犠牲にしてでも高級な機能を持つ言語が欲しいのなら
最初からC/C++は選択肢に入らないだろ。見えてないのはお前の方だ。

425 :デフォルトの名無しさん:2008/10/03(金) 04:34:31
その低劣な生産効率を補えるほどに速くすらないのが問題なんだろ

vtbl持たなきゃならないのはオブジェクト指向言語の本質的な非効率性だから
C++でも他でも一緒だしな

426 :デフォルトの名無しさん:2008/10/03(金) 04:39:32
他の言語は知らないが、GNUとMSのコンパイラは
純仮想関数を使わない限りVTBLは使われないよ

427 :デフォルトの名無しさん:2008/10/03(金) 04:54:09
そりゃ使わない物は使わないし、まともなコンパイラなら省くに決まってる

でも継承を有効利用するにはvtblはないわけにはいかない
継承と多態性はオブジェクト指向の根幹だ

428 :デフォルトの名無しさん:2008/10/03(金) 05:03:58
だから、継承とプリモにはVTBLは必要ないぞ
COMとか使ったこと無いか?アレだ

429 :デフォルトの名無しさん:2008/10/03(金) 05:07:31
インスタンスが自分が何者かを知らずにどうやってポリモやるんだ?

430 :デフォルトの名無しさん:2008/10/03(金) 05:11:22
オブジェクト指向がどうこうってより、同じような設計をしようと思ったら
Cでやっても同じようなコード(vtblと同じ、関数アドレスを介した呼び出し)になるわけで。
原理的に無理なものをどうこう言っても仕方無いだろ。

ただ、D&Eに「多重継承をサポートする為に、vtblを”単一継承なら使える最も速い方法”で
実装しなかった(加算1つと代入1つ増えた)。ここだけは唯一ゼロオーバヘッドルールに
違反することになった」って書いてあったけども。

それすら気になるほど速度を重視するのならそもそも仮想関数を使わないor
vtblが必要になるような仮想関数の書き方をしなければいい。
そんな滅茶苦茶ギリギリで設計の自由度も無い状況で仮想関数使うような
多態性を用いる設計を使おうとする方がおかしい。

>>428
あまり詳しくないがCOMはvtbl使ってるはずだよ。

431 :デフォルトの名無しさん:2008/10/03(金) 05:14:35
>>430
そうそう
だから効率が重要な場合はあらゆるOO言語は使えないってこと
それはC++だろうとなんだろうと一緒な訳で

432 :デフォルトの名無しさん:2008/10/03(金) 05:26:13
勘違いさせたが、手続き型言語においてVTBLが必要となる一つの条件としてCOMを挙げた
手っ取り早くは適当にリバースエンジニアしてもらえればわかるのではないだろうか
あくまで、コンパイラの実装の話だけどね

433 :デフォルトの名無しさん:2008/10/03(金) 05:42:21
>>412,413
結局何も説明できずに馬鹿って言うだけなの?。なんなの?バカなんですか?
C++のなにが難しかったんですか?何がわからないのかわからないのですか?

434 :デフォルトの名無しさん:2008/10/03(金) 05:47:37
>>433
真性の馬鹿に何かを教える様な物好きに、そんな簡単にめぐり合えるとでも思ってるの?

435 :デフォルトの名無しさん:2008/10/03(金) 05:54:05
何か眠気でちゃんと読んでないのかな
C++は手続き型言語
要するに仮想関数程度じゃインスタンスを特定できるから
オーバーヘッドはCの関数を呼び出すのと引数分しか差がない

純仮想関数のようにインスタンスを特定できない場合に限り
VTBLを通して関数が呼び出される
これはルックアップテーブルだからそれなりに高コスト

こんなもんで理解してくれ

436 :デフォルトの名無しさん:2008/10/03(金) 05:54:57
あ、ただのバカアンチなんですね。了解しました。テンプレートは難しいですもんね。
VisualBasicという言語をお薦めしておきます。

437 :デフォルトの名無しさん:2008/10/03(金) 05:59:09
>要するに仮想関数程度じゃインスタンスを特定できるから
何だものすごいバカか

438 :デフォルトの名無しさん:2008/10/03(金) 06:01:23
>>435
仮想関数はvtbl使わなくて純粋仮想関数は使うって言ってるの?
本気で言ってるの?

よく眠って頭冷やせよ

439 :デフォルトの名無しさん:2008/10/03(金) 06:32:06
仮想関数批判はC++というかJavaとかC#とかもろもろ全部だしあんまし
意味ないような。
しかもそんな奴はむしろC++でメタテンプレートでも極めればいいし
C++向きだと思うが。

440 :デフォルトの名無しさん:2008/10/03(金) 06:47:47
OOの本質的なオーバーヘッドとC++固有の問題を
ごっちゃにして叩く輩が多いからな

441 :デフォルトの名無しさん:2008/10/03(金) 09:30:53
MFCはSTLが固まる前に発売されたから勝手に作った独自仕様などと言れれるゆわれはない。

442 :デフォルトの名無しさん:2008/10/03(金) 10:06:47
>>436
TMPなんぞを嬉しがってるのはC++信者だけだろ

パターンマッチングやダックタイピング/structural subtyping、
ファーストクラスの関数、lambda式、クロージャ
今時の高級言語がもっとマシな形で備えている機構が無いために
C++信者はあの醜く汚いバッドノウハウを金科玉条のごとくに
有難がってるんだろ
しかもC++からソースレベルでしか再利用できないというデッドな技術だから
C++信者はあくまでもC++にしがみつくしかない
タコツボだな

443 :デフォルトの名無しさん:2008/10/03(金) 10:26:23
>>442
>>436のアイデンティティが崩壊しちゃうからそれ以上言っちゃダメ

444 :デフォルトの名無しさん:2008/10/03(金) 10:35:40
>>442
お前みたいな流行りの言語機能好きは流行りの言語をそのときどきに勉強して
使ってればいいんじゃねーの?
Haskellでlambda使いまくりのWindowsプログラミングでもやってりゃいーじゃん。
なぜそれが現実的じゃないのか、なぜ誰もやってないのか、なぜ言語機能だけで
ソフトは作れないのかを知るといいと思うよ。

445 :デフォルトの名無しさん:2008/10/03(金) 10:38:54
>>444
Javaですらlambda式やクロージャを取り入れようとしてるのに今更何言ってんだ?

446 :デフォルトの名無しさん:2008/10/03(金) 10:45:19
>>444
自分に都合の良い解釈ばっかしてると馬鹿に見えるよ

447 :デフォルトの名無しさん:2008/10/03(金) 10:45:27
Cより古いLispをガン無視して単なる「流行」とか言ってるのが笑えるな

448 :デフォルトの名無しさん:2008/10/03(金) 10:46:53
連投乙

449 :デフォルトの名無しさん:2008/10/03(金) 11:01:49
>>445-447
そんなにむきになるなよ。お前は悪くない。時代が悪いんだ。

450 :デフォルトの名無しさん:2008/10/03(金) 11:04:37
>>449
いや、単純にお前の頭が悪いんだよ。

451 :デフォルトの名無しさん:2008/10/03(金) 11:11:46
お前らどんだけ馬鹿馬鹿言い合えば気が済むんだよw

452 :デフォルトの名無しさん:2008/10/03(金) 11:29:44
>>435
本当にC++を知っているとは思えない発言だな

仮想関数があるなら必ずvtblは作られる
静的に型が確定している場合(参照を通さない場合)には、
vtblルックアップは要らない
ポインタや参照の場合は静的に型が確定しないので、仮想関数の場合は
常にvtblルックアップが発生する

こんなのは常識だろ
つーか、C++でどうやってポリモーフィズムを実現してると思ってるんだ

453 :デフォルトの名無しさん:2008/10/03(金) 11:32:37
自分の知っている処理系は全てvtblだが
C++にはvtblを用いて実装しなければいけないという決まりはなかったはずだが

454 :デフォルトの名無しさん:2008/10/03(金) 11:34:23
>>453
ああ、確かにちと実装より過ぎる説明だったか
いずれにせよ>>435が言っていることは明らかな誤り

455 :デフォルトの名無しさん:2008/10/03(金) 11:40:10
つっても店頭に並んでるアプリの9割はいまだにC++製だからなあ。
やっぱOSネイティブの言語は機能どうこう以前の強力さがあるんだよな。
まあC++にもlambda/bindが来年付くしまだまだ現役続投かねぇ。

456 :デフォルトの名無しさん:2008/10/03(金) 11:43:13
>>455
Windowsと同じだな
シェアそれ自体が最大の強み
言語が糞でもな……

457 :デフォルトの名無しさん:2008/10/03(金) 12:02:07
マイナーなもの使って人柱やるのもいやだしな

458 :デフォルトの名無しさん:2008/10/03(金) 12:03:28
>>417
C++マンセーな俺も、それには同意。

459 :デフォルトの名無しさん:2008/10/03(金) 12:22:20
>>402以降、誰もC++の開発効率に触れないのな

460 :デフォルトの名無しさん:2008/10/03(金) 12:27:21
え、>>402以降リロードせず>>459を書き込んじゃったの?

461 :デフォルトの名無しさん:2008/10/03(金) 12:30:00
Office や Web ブラウザのような巨大で複雑なアプリをサクサク動かすには
今のところ C++ しか選択肢はないんじゃないか? D はよく分からないが。

462 :デフォルトの名無しさん:2008/10/03(金) 12:36:04
>>460
具体的にどのレス?

ちなみに402は↓これだぞ?
>素朴な疑問なんだが
>C++がCより開発効率が良いって主張あるよな?
>ひとによっては暗黙の了解になってるぽいんだが
>それって誰がいつどうやって比べたの?
>ソースはあるの?

463 :デフォルトの名無しさん:2008/10/03(金) 12:36:48
MacではC++じゃなくてObjective-Cが母語なんだろ
だから、C++でなければならないというわけでは全くないだろう

少なくともOfficeみたいなリッチなOSの上に乗っかって動くアプリなら、
ネイティブコンパイルさえ出来れば、もっと動的な言語でも十分ってことになるん
じゃないのか

464 :デフォルトの名無しさん:2008/10/03(金) 12:44:53
>>462
単品のレスじゃなくて流れで分かるだろ

>>402には「C++がCより開発効率が良いがひとによっては暗黙の了解になってるぽいんだがソースは無い」でこのスレ的にはFA出てる
何かしら覆したいならお前がソース出せ

C++単品の生産効率についてなら腐るほど言い合ってるだろ

465 :462:2008/10/03(金) 12:59:24
>>464
いや別に覆したいとは思ってないよ、事実関係をはっきりさせたいだけ
じゃあこのスレ的には「C++の開発効率はCより高いとは言えない」でFAだな

466 :デフォルトの名無しさん:2008/10/03(金) 13:15:19
>>465
大した根拠も無くC++の方が開発効率が良いと思ってる奴は確実に居るが、本当の所は誰も知らんがFA

467 :デフォルトの名無しさん:2008/10/03(金) 13:15:26
C++はCを内包するので比較する意味が無い

468 :デフォルトの名無しさん:2008/10/03(金) 13:18:04
また馬鹿が湧いた

C++はCを内包するので比較する意味が無い(キリッ

いくらかマシに見える様に訂正しときました

469 :デフォルトの名無しさん:2008/10/03(金) 13:19:47
>>467
>>415
スーパーセットは時にサブセットに劣る

470 :デフォルトの名無しさん:2008/10/03(金) 13:25:17
スーパーセットである事によるオーバーヘッドが有意か否かは
開発者自身や処理系の問題であって言語の問題では無い

471 :デフォルトの名無しさん:2008/10/03(金) 13:26:26
カプセル化できるだけでも有難い<C++
まあ「隠匿されたら処理の流れが解らんではないか!」とか
言い出す奴にとっては厄介なんだろうが。

472 :デフォルトの名無しさん:2008/10/03(金) 13:30:42
>>470
肥大化した仕様はまさに言語の問題だろう

さらにC++の場合は禿が実用性を謳ってるんだから開発者や処理系の都合も言語とセットで考えるべき

473 :デフォルトの名無しさん:2008/10/03(金) 13:34:32
C++ は基本的にサブセット(C部分)に劣らない。
C 部分の性能は普通の処理系なら落ちないから。

474 :デフォルトの名無しさん:2008/10/03(金) 13:43:43
>>473
流れ嫁よ
(実行時の)性能を比較してるわけじゃないだろ

475 :デフォルトの名無しさん:2008/10/03(金) 13:48:42
じゃあ、何が劣るの?

476 :デフォルトの名無しさん:2008/10/03(金) 13:52:41
「C++なんて駄目。Cの方がまし」という事にしたがっている奴の脳。

477 :デフォルトの名無しさん:2008/10/03(金) 14:06:15
C++ は C よりもコンパイラの選択肢が少ないところが劣っているかな。
俺はそんなことで困ったことはないけど。

478 :デフォルトの名無しさん:2008/10/03(金) 15:13:33
C++が一番ひどいのは学習コストだろう?
罠とバッドノウハウが多すぎる
そしてそこまでして学習したものは、C++を使うとき以外何の役にも立たない
だからこそ「バッドノウハウ」なんだけどな

479 :デフォルトの名無しさん:2008/10/03(金) 15:39:00
boostはC++を象徴してる
言語仕様の貧弱さを無理やりカバーするためにマクロとテンプレート使いまくり

お陰で糞みたいにコンパイル時間がかかるわ
解読不能なエラーメッセージを大量に出力するわ
仕方がないからソース読もうにも追う気すら萎えさせるわ
インテリセンスはクラッシュさせるわ

プログラマの時間をドブに捨てさせるにはこれ以上ないいい言語だと思う

480 :デフォルトの名無しさん:2008/10/03(金) 15:41:44
標準でソケット通信ライブラリすら無いんだから規模はむしろ小さい方だろう
Cよりは当然覚える事は多いが

481 :デフォルトの名無しさん:2008/10/03(金) 15:56:55
C++作った理由の陰謀論みたいな話になってきたなw

482 :デフォルトの名無しさん:2008/10/03(金) 17:33:26
ねぇ、C++擁護派ってなんでこんな馬鹿なの?ねぇ、なんでこんな馬鹿なの?

483 :デフォルトの名無しさん:2008/10/03(金) 17:45:55
オブジェクト指向だけに、先人の思想を忠実に継承してるからな。

484 :デフォルトの名無しさん:2008/10/03(金) 17:48:07
反対派も大概バカだけどな
結局は適材適所
C++はアプリを作るには最低の言語
ドライバやミドルウェアを作る時にはそこそこ役に立つ言語
それでいいじゃないか

485 :デフォルトの名無しさん:2008/10/03(金) 17:54:49
お前らプログラムもろくに組めない癖に文句だけは一丁前に言うなw

486 :デフォルトの名無しさん:2008/10/03(金) 17:56:53
ツンデレなんだよ

487 :デフォルトの名無しさん:2008/10/03(金) 18:03:51
継承も例外もオーバーロードもテンプレートもなくして
クラスがメンバ関数とコンストラクタとデストラクタを使えるだけのちょっと便利な構造体なだけだったらよかったのに

488 :デフォルトの名無しさん:2008/10/03(金) 18:05:35
つか否定派と比べて擁護派が非論理的すぎるだろ

489 :デフォルトの名無しさん:2008/10/03(金) 18:10:17
特定分野では役に立つこともあるよねってだけで擁護派扱いか
ありとあらゆる局面で絶対に役に立たないクソ言語でないと気が済まないって人たちの方が怖いです

490 :デフォルトの名無しさん:2008/10/03(金) 18:13:46
ネイティブコンパイルできて、Cやasmのobjとリンクできるなら
何でもよくね?

組み込みに関しては、Javaみたいにエディション分けちゃえばいいのにと思う。
EC++とかは消えたんだろ?

491 :デフォルトの名無しさん:2008/10/03(金) 18:21:50
>>484
基本的に反対派の主張は>>484に書かれてる通りなんですけど?

馬鹿で非論理的な擁護派が勝手に>>489みたいに被害妄想炸裂させて
反対派の奴らはこんな極端な事を考えているキチガイだったんだよ!!!11って五月蝿いだけなんです。
だから擁護派はなんか馬鹿が多いって言われてるんです。
わかりますか?

492 :デフォルトの名無しさん:2008/10/03(金) 18:26:11
>>441
そうだとしても、STLが策定された時点でSTLベースに作り直すのが筋だろ?

493 :デフォルトの名無しさん:2008/10/03(金) 18:30:23
>>492
MFCを作り直す必要はないんじゃないか?
モダンなC++として書けばATL/WTLのようにただの別物が出来上がるだけで
それに「MFC」という名前をつける必要がない

MFCの導入時はWin16からWin32への移行促進という目的があった
(ある意味今の.NETに似てる)
今や単なるレガシー技術の互換性サポートだろ

494 :デフォルトの名無しさん:2008/10/03(金) 18:34:06
>>492
どっちでもいいだろ
どうせウィンドウズが亡くなったらC++の使い道なんか殆ど無いんだしw

495 :デフォルトの名無しさん:2008/10/03(金) 18:36:38
>>492
準拠するに足る魅力が無かったってだけだろ

496 :デフォルトの名無しさん:2008/10/03(金) 18:47:19
MSC7.0だっけか

497 :デフォルトの名無しさん:2008/10/03(金) 19:23:44
>>492
そんな筋はないと思うぞ。
過去のMFCと互換性ぶったぎることになるだろうし。

498 :デフォルトの名無しさん:2008/10/03(金) 19:34:27
>>490
一応、ホスト環境とフリースタンディングって区分けが標準にある。
誰も意識していないけど……。

499 :デフォルトの名無しさん:2008/10/03(金) 19:57:41
492 タコ殴りw

500 :デフォルトの名無しさん:2008/10/03(金) 20:07:38
未来の言語

C{
ここC文法領域
}

C++{
ここC++文法領域
}

Perl{
ここPerl文法領域
}

もうこんなのでいいよ

501 :デフォルトの名無しさん:2008/10/03(金) 20:10:31
むかしXMLでそんなことしてるのがあったな

502 :デフォルトの名無しさん:2008/10/03(金) 20:32:59
>>500
http://search.cpan.org/~ingy/Inline-0.44/Inline.pod
もっとだいぶ鬱陶しいけど、もう Perl にあるから全部 Perl でいいね。

503 :デフォルトの名無しさん:2008/10/03(金) 21:43:06
Союз Советских Социалистических Республик

504 :デフォルトの名無しさん:2008/10/03(金) 22:00:19
>>465
いろんな統計を見たことがあるはずだが、手元にある分では、行数に関するものしか見つからなかった。
Code Complete とラピッドデベロップメントに、ファンクションポイントあたりの行数が C の方が C++ に比べて 2.5 倍多いそうな。

505 :デフォルトの名無しさん:2008/10/03(金) 22:29:31
>>504
ただの興味なんだが、その「いろんな統計」が是非見てみたい。
個人的には「ファンクションポイントあたりの行数」では開発効率は測れない(根拠として弱すぎる)と思うし。

506 :デフォルトの名無しさん:2008/10/04(土) 01:23:33
>>492

確かに筋だな。
ttp://up2.viploader.net/pic2d/src/viploader2d465723.jpg

507 :デフォルトの名無しさん:2008/10/04(土) 01:36:10
↑面白い事をやったつもり

508 :デフォルトの名無しさん:2008/10/04(土) 02:13:47
>>494
言っておくが家庭用ゲーム機およびPCのゲームは殆どC++だぞ
一昔前はCで開発してるところも多かったが。
携帯ゲームはほとんどがJavaだが。
想像力無さ過ぎ。よくそれでプログラマやってられるな

509 :デフォルトの名無しさん:2008/10/04(土) 02:15:16
訂正、携帯電話のゲームは。

510 :デフォルトの名無しさん:2008/10/04(土) 08:36:46
どうして開発言語が C から C++ に移行したの?

511 :デフォルトの名無しさん:2008/10/04(土) 09:01:16
>>510
ゲーム開発の規模がデカくなり、プラットフォームをまたいで開発することが
増えるに従って、毎回書きなおしするような開発は非効率すぎるということで
業界全体がそういう流れになったんだと思う。
勿論Cでもマルチプラットフォームで使いまわしの利くコードは書けるけど、
それだけのセンスがあるなら、C++でプラットフォームをまたぐクラスライブラリを書けるし、
よっぽど解りやすくて保守しやすいコードになる。
かといって富豪プログラミングが許されるわけではないし(オブジェクトが裏でやっていることの
時間的・空間的コストが想像もつかないようでは話にならない)、アセンブリ叩く場面もあるけども。
中小では未だにCのところもあるみたいだけどね。

512 :デフォルトの名無しさん:2008/10/04(土) 12:41:29
>>511
なるほど。
ゲームでは C++ が C より生産性が高いということですね。

513 :デフォルトの名無しさん:2008/10/04(土) 12:45:37
一般論としては、OOが非常に適している分野とそうでもない分野があると思う
関数型が向いている分野とそうでない分野があるように

GUI、シミュレーションなんかはモロにOO向きで
ゲームもそれに相当するだろう

CでOOっぽいことも出来るが、デバドラぐらいならともかく
Xのツールキットぐらいの規模になると結構苦しい印象があるな

514 :デフォルトの名無しさん:2008/10/04(土) 13:56:46
>>512
待った、いちがいにそうとはいえない
業界最大手クラスのゲームデベロッパでは例外とSTLとBoostとRTTIとほぼ全ての演算子オーバーロードとほぼ全てのテンプレートが禁止だよ
その他の大手も大同小異だ
それってC++なのか?

515 :デフォルトの名無しさん:2008/10/04(土) 14:10:51
>>514
例外やBoostやRTTIはわかるが(コンシューマなら特に)、テンプレート禁止ってのはわからんな。
一体どこの会社を指して業界最大手とか大同小異だとか言ってるのか知らないが
クラス使ってりゃ十分C++だと思うけど。
まさかツール作るときもそれら全部禁止なの?
数値演算まわりのクラスにも演算子オーバロード禁止?

516 :デフォルトの名無しさん:2008/10/04(土) 14:12:06
C++を使わないと企画が通らないけど
C++を使うと開発が立ち行かない

517 :デフォルトの名無しさん:2008/10/04(土) 14:24:56
つーかさ、同じC++でも例外の有無でまったく別の言語だよな
コードの再利用なんて不可能なんだし

518 :デフォルトの名無しさん:2008/10/04(土) 14:29:55
>>515
不安定な俺クラスよりも、boostの同様なクラスを使ったほうがコードがすっきりしたりする。

.俺の10年がboostに塗りつぶされていって泣けるorz



519 :デフォルトの名無しさん:2008/10/04(土) 14:36:08
本来C++の諸機能と例外は不可分なんだが
なぜか世の中には例外無しのC++という処理系や開発現場がある

ハゲが泥縄式に例外を導入した歴史的経緯なんでもうあきらめるしかないが
処理系提供側も例外使えないならC++を名乗らないで欲しい

520 :デフォルトの名無しさん:2008/10/04(土) 14:47:27
別に言語の全ての特徴を実際に使うかどうかは関係ないでしょw
使わないコードでもバイナリレベルにどうしても影響しちゃうとかならしょうがないけどw

521 :デフォルトの名無しさん:2008/10/04(土) 14:50:55
>>515
演算子やテンプレートは決められた人間が作ったものだけ使えっていうことじゃないかな。
例外を禁止する理由は良く分からないが処理系によっては例外を投げなくても重くなる
可能性があるからかな。

522 :デフォルトの名無しさん:2008/10/04(土) 14:55:12
コンストラクタの失敗とかはは例外以外のまともに捕まえる方法がないからな言語的に
結局errnoみたいなものに頼ることになって何のためのオブジェクト指向なのかという話に

523 :デフォルトの名無しさん:2008/10/04(土) 15:10:54
> 演算子やテンプレートは決められた人間が作ったものだけ使え

それって出来の悪い兵隊集めて仕事する三流請負業務系の発想だな
現在そういう系統ではC++は死滅していると認識しているが

524 :デフォルトの名無しさん:2008/10/04(土) 18:49:49
>>522
class hoge { ... };
hoge a;
if(!a.ok()) goto hell;

でいいんじゃね?

525 :デフォルトの名無しさん:2008/10/04(土) 18:53:59
お話になられません。

526 :デフォルトの名無しさん:2008/10/04(土) 19:18:06
といいますか、コンストラクタ内で自己完結してない時点でOOとしてはお話になりませぬ。

527 :デフォルトの名無しさん:2008/10/04(土) 19:26:18
ANSI C++ 1998
ANSI C++ 2003
ときて、
C++0
が採択される、まだまた拡張中。

528 :デフォルトの名無しさん:2008/10/04(土) 19:40:30
>>524
a の初期化に失敗した後は a は存在しないはず。
だから a にはアクセスできない。

529 :デフォルトの名無しさん:2008/10/04(土) 19:44:30
>>528
そこで言う「失敗」て例えば何なん?

530 :デフォルトの名無しさん:2008/10/04(土) 19:52:05
>>528
>>524は、iostreamのように、失敗しても例外を投げないような設計にしてある
ことが前提なんでしょ


531 :デフォルトの名無しさん:2008/10/04(土) 20:34:59
>>529
よくあるのがメモリ確保に失敗した時

532 :デフォルトの名無しさん:2008/10/04(土) 20:36:29
>>530
ああ、確かにそういう初期化に失敗しない設計もできるね。
しばらく RAII な設計をしてきたからそういうのは思いつかなっかた。
例外のない C++ だとクラス設計もかなり変わってくるな。

533 :デフォルトの名無しさん:2008/10/05(日) 00:00:41
某有名ゲームエンジンはC++でOOしまくり例外多用だけどね。
言語の文句ばっか言ってモノ作れないボンクラは原因は別のとこにあると思う。

534 :デフォルトの名無しさん:2008/10/05(日) 00:07:19
C++→肥大化
Ruby→肥満化

535 :デフォルトの名無しさん:2008/10/05(日) 00:12:10
Windows アプリ開発の主力言語が C から C++ になってしまったのは MS のせい?
MS に否定的な OpenOffice や Firefox まで C++ で開発しているみたいだけど。

536 :デフォルトの名無しさん:2008/10/05(日) 00:27:06
パソコン屋で売ってるソフトの90%くらいがWindows用
そのほとんどがVCで残りがVBかBCCかDelphi

537 :デフォルトの名無しさん:2008/10/05(日) 02:03:05
>>535
なんでもMSに結びつけるのは違うだろ。

538 :デフォルトの名無しさん:2008/10/05(日) 03:37:13
てか何年前の話だww
C#に移るのかって時代に

539 :デフォルトの名無しさん:2008/10/05(日) 03:47:22
ww

540 :デフォルトの名無しさん:2008/10/05(日) 03:59:28
>>533
>モノ作れないボンクラは原因は別のとこにあると思う。

モノ作れないのと言語の文句を言うのは全く別の話だと思う。

541 :デフォルトの名無しさん:2008/10/05(日) 04:52:27
結局擁護派って自分で書いたコードしか弄った事無いから擁護できるんだよな
発言から視野の狭さが見て取れる

542 :デフォルトの名無しさん:2008/10/05(日) 05:16:10
>>541
俺にはその擁護を否定に入れ替えるとその通りに思える
それともアレか、バカが書いたC++のコードを弄ってるとC++が嫌いになるとかか?
擁護否定に関わらず、バカが書いたC++のコードがクソなのは誰もが知ってると思うが。

543 :デフォルトの名無しさん:2008/10/05(日) 05:30:04
バカが書いた世界地図を思い出した

544 :デフォルトの名無しさん:2008/10/05(日) 05:44:08
>>542
これはひどい

545 :デフォルトの名無しさん:2008/10/05(日) 06:36:07
>>541
その文面からは視野の広さが見て取れない

546 :デフォルトの名無しさん:2008/10/05(日) 10:07:57
スレタイとどんどん離れてくなw

547 :デフォルトの名無しさん:2008/10/05(日) 10:43:15
ただのバカスレだしな

548 :デフォルトの名無しさん:2008/10/05(日) 10:53:15
スレの趣旨とは合致してるからまったく無問題
すぐ顔真っ赤になるC++信者を見守るスレです

549 :デフォルトの名無しさん:2008/10/05(日) 11:44:56
アンチまっさお、信者まっか

550 :デフォルトの名無しさん:2008/10/05(日) 13:08:17
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。

551 :デフォルトの名無しさん:2008/10/05(日) 13:09:17
C++ のようにマルチパラダイム言語はプログラミングが楽だ。
複数の言語でプログラム断片を作ってつなぎ合わせる方法は結構面倒くさい。

552 :デフォルトの名無しさん:2008/10/05(日) 13:24:05
C++のプログラミングが「楽」とか正気とは思えん
LLなら数行で済む仕事に一体何行かける気だ

言語は適材適所で使えよ
ネイティブなobjを吐く言語は要するに高級なアセンブラなんだからよ

553 :デフォルトの名無しさん:2008/10/05(日) 13:50:23
末端作業員はPerl永遠にやってな

554 :デフォルトの名無しさん:2008/10/05(日) 13:51:47
1つのプログラムは GUI からレイトレの計算までいろいろな部分が混在してる。
これらをそこそこカバーできるメジャーな言語は C++ 以外に何がある?
そのぞれの部分に得意な言語を使うこともできるがリンクが面倒くさくなる。

555 :デフォルトの名無しさん:2008/10/05(日) 13:53:40
低所得スクリプターが紛れ込んで奮闘してるんだろ。

556 :デフォルトの名無しさん:2008/10/05(日) 14:02:41
厨房はこれだから困る

今時ゲームだってLuaだのPythonだのスクリプトエンジンの一つや二つ
入れ込んでるだろ
gaucheの作者はスクウェアでCGのプロダクションシステムをLispで書いてる
というかLispは昔からCG分野で主流で、今はPythonが取って代わっている
Emacsは実際にはLispインタプリタで、だからこそあれだけ強力なエディタなんだ

557 :デフォルトの名無しさん:2008/10/05(日) 14:08:44
馬鹿が書いたコードは言語問わず糞だが
他言語に比べてC++は馬鹿が糞コードを非常に書きやすい
しかもC++では優秀な開発者でもバッドノウハウを身に付けないと危険なコードの罠にはまる

558 :デフォルトの名無しさん:2008/10/05(日) 14:35:18
C++&Python最強ということで終了

559 :デフォルトの名無しさん:2008/10/05(日) 15:16:54
>>556
それはかなり金をかけて作られるゲームエンジンに統合されているからできること。
普通のアプリでそういうことをやろうとするとデバッグも含めてかなり面倒くさい。
COM や .NET で多言語のリンクをしたほうがまだまし。

C++ は C が得意な部分、OO が得意な部分、テンプレートなどを自然な形で結合できる。
これを作った禿は天才

560 :デフォルトの名無しさん:2008/10/05(日) 15:28:53
C++ に慣れちゃったからそれが自然なだけでしょ。
「言語は人間を規定する」という訳だ。

561 :デフォルトの名無しさん:2008/10/05(日) 15:38:13
>>559
「普通のアプリ」とやらが何をさしてるんだかわからんが
趣味で作ってるおもちゃのフリーソフトのことなら、好きにすれば?
趣味なんだしな


562 :デフォルトの名無しさん:2008/10/05(日) 16:17:12
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
と、相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。

563 :デフォルトの名無しさん:2008/10/05(日) 16:37:54
>>552
ちゃんとした仕組みを作り上げれば、楽になるのだと思う

でも・・・ ねぇ、、 その時間と楽さのトレードオフがなってないよ
それに気づけない人がC++にのめりこんじゃうと本当に時間無駄にしてる
それが楽しいならいいけど
C++は、根底だけ用意して土台が何も無いから・・・
そういう人が土台を一生懸命作ってる感じ
あと、何年したらまともな土台になるのやら

564 :デフォルトの名無しさん:2008/10/05(日) 17:02:09
>>552
Cやアセンブラと比較すれば、相対的にまし程度のことだと思う。

565 :デフォルトの名無しさん:2008/10/05(日) 17:15:45
C++のデストラクタのような頑強な後処理をCを使って手作業で書くことを考えるとうんざりしてしまう。

566 :デフォルトの名無しさん:2008/10/05(日) 17:23:24
>>563
仕組みというのがライブラリのことを言ってるんなら無駄
簡単な話だ、アセンブラにライブラリやマクロを山ほど乗っけたら幸せになるか?
アセンブラはどこまで行ってもアセンブラだよ
C++も同じことさ

567 :デフォルトの名無しさん:2008/10/05(日) 17:46:55
でも、Cと同じようにも書けるから
上手くC言語拡張として使うだけなら、良いと思うんだけどなぁ(俺はそう使ってる
ベターCから抜け出せない? なんとでも言うが良いよ

だから個人レベルでC++使うのはいいけど、大勢でC++使うのは勘弁です....

568 :デフォルトの名無しさん:2008/10/05(日) 17:54:05
ベターCとは言うけどどの辺がベターなの?
OOとか例外とかテンプレートとか演算子オーバーロードとか便利(ということにしたがってる)な機能を
全部捨ててなおCよりベターな所って何?

569 :デフォルトの名無しさん:2008/10/05(日) 17:54:21
引きもっこりがなにいってんだか

570 :デフォルトの名無しさん:2008/10/05(日) 17:59:17
>>567
>大勢でC++使うのは勘弁です....

激同。
何がベターかは人それぞれだから、足並みを揃えるのが大変そう。

571 :デフォルトの名無しさん:2008/10/05(日) 18:05:01
C の方が大勢で使うのは勘弁
アクセス制御やデストラクタがないのは危なかしい。

572 :デフォルトの名無しさん:2008/10/05(日) 18:10:50
そんな些細な便利機能のためだけに他の爆弾を大量に持ち込む方が馬鹿げている

573 :デフォルトの名無しさん:2008/10/05(日) 18:13:56
だから571のところでは、テンプレート禁止とかいろいろ制約かけるんでしょ?
それだけで572の言うところの爆弾を抑えきれるかどうかは知らないけど。

574 :デフォルトの名無しさん:2008/10/05(日) 18:25:12
テンプレートやインライン関数の代わりにマクロ使いまくるほうが爆弾
例えば C++ にはどんな爆弾がある?

575 :デフォルトの名無しさん:2008/10/05(日) 18:30:41
いまさらC++がむずいとか・・ww・・ゆとりには確かに無理www

576 :デフォルトの名無しさん:2008/10/05(日) 18:30:43
C のマクロと C++ のテンプレートの使用頻度が全く異なるのは見ない振りですか?

577 :デフォルトの名無しさん:2008/10/05(日) 18:30:56
つーか、実際というか仕事の場合、ライブラリとかでどうせ制限されるんだから、
言語がどうのってのはないだろw

いくら優秀な言語でも誰も知らんかったら、実用性ゼロだw

578 :デフォルトの名無しさん:2008/10/05(日) 18:42:20
マクロなんて簡単だろ
所詮文字列の置き換えなんだから挙動も明確だしあとからいくらでも追跡できる

テンプレートはカオスすぎて人間が追いかけるのは不可能

579 :デフォルトの名無しさん:2008/10/05(日) 18:46:12
テンプレートもmplまで行くと
チャーチ数とかbrainf*ckとかgrassみたいなのに似たノリを感じる

パズル好きが趣味で遊ぶオモチャとしてはいいんだろうけどな

580 :デフォルトの名無しさん:2008/10/05(日) 18:46:30
いつからテンプレートが危険視されるようになったんだ。
テンプレートメタプログラミングなら分からないでもないが
そもそも理解できていないやつがそんなもの作るとも思えないし。

581 :デフォルトの名無しさん:2008/10/05(日) 18:48:15
>>578-579
Boost.Preprocessorもやばい。

582 :デフォルトの名無しさん:2008/10/05(日) 18:52:33
テンプレートはデバッガがデバッグをサポートしているからまだいいよ。
普通マクロはデバッガで追跡できない。

583 :デフォルトの名無しさん:2008/10/05(日) 18:53:03
>>568
型チェックがしっかりしてるところ。

584 :デフォルトの名無しさん:2008/10/05(日) 19:16:15
>>582
デバッガで追えなくて困るほどマクロを多用する事は無い
テンプレートとは違う

585 :デフォルトの名無しさん:2008/10/05(日) 19:18:01
テンプレートはtypedefの奥底にいつ潜んでるかわからないからな
マジで地雷と変わらん

586 :デフォルトの名無しさん:2008/10/05(日) 19:45:03
Cの場合同じような処理を繰り返し書くからマクロなんてそんなに使わないよ。

587 :デフォルトの名無しさん:2008/10/05(日) 19:50:34
いい加減、C++使ってるとにコストがペイ出来ない状況になってる事に気付いたら?
ドライバや3Dゲーム、フレームワーク作ってる人らはいいんだけど、それ以外のヌケサク共はさ

588 :デフォルトの名無しさん:2008/10/05(日) 19:57:43
Cでメタプロっぽいことをやるときは
他言語でのソース生成/(cppではない)プリプロセッサを使うのが常道だろう
cppは貧弱だから、出来ることもたかが知れている

>>587
なぜそこで「フレームワーク」w
フレームワークビジネスってのは上に乗っかる馬鹿な兵隊がいるから
成り立つもんだろう

589 :デフォルトの名無しさん:2008/10/05(日) 20:17:20
弱小の無名詐欺フレームワークは含んで無いよ

590 :デフォルトの名無しさん:2008/10/05(日) 21:30:02
Cでマクロなんかほぼ使わないし見ないぞ
マクロが危険て奴の職場はどんだけレベル低いんだ?
そんな奴らはCだろうがC++だろうが変わらんだろう

591 :デフォルトの名無しさん:2008/10/05(日) 22:38:11
たまに他のプログラマが作ったマクロと識別子がぶつかって悩まされる。
ひどいときは小文字1文字のマクロがあって原因の特定に時間がかかる。
UNIX のヘッダーでさえ major とか定義していてわけが分からなかった。

そのほかにも引数が複数回評価されたり、型がチェックされなかったりすることがある。

592 :デフォルトの名無しさん:2008/10/05(日) 23:03:03
じゃあ名前ぶつかってもオーバーロードで華麗にスルーするC++は最悪ですね

593 :デフォルトの名無しさん:2008/10/05(日) 23:05:51
>>591
全部、殆どありえないケアレスミスじゃん…

594 :デフォルトの名無しさん:2008/10/05(日) 23:12:08
>>592
型に従うから大丈夫。名前空間使うから他人のものとぶつかる確率は低い。
>>593
他人が作ったものだから避けられない。

595 :デフォルトの名無しさん:2008/10/05(日) 23:15:27
いや、避けられないとかじゃなくてさ、そんな状況は現実世界じゃ発生しないのよ。
「たまに」とか「ひどいとき」とかいうレベルじゃない。

596 :デフォルトの名無しさん:2008/10/05(日) 23:20:46
何を言っても今後 C++ が良い言語に生まれ変わる訳でもないし、
世間の評価が上がる訳でもないから仕方が無いね。どうしても
必要なら使うけど、そうでなければごめん被りたい。

597 :デフォルトの名無しさん:2008/10/05(日) 23:29:13
>>595
594は別世界の人間なんだから、お前はそっとしてやれ。

598 :デフォルトの名無しさん:2008/10/05(日) 23:30:38
C++のネイチブコンパイル出来たら西京

599 :デフォルトの名無しさん:2008/10/06(月) 00:04:49
MIN(x,y)とかMAX(x,y)を標準のCプリプロで副作用無しで書けるか?

600 :デフォルトの名無しさん:2008/10/06(月) 00:10:34
C++擁護派はCのスーパーセットって何度も主張してるけどさ
だったら>>591の問題は全てC++でも起こることになるよ
当然それにプラスしてC++固有の問題も起こるから、Cより問題点が多いってことになっちゃうよ

601 :デフォルトの名無しさん:2008/10/06(月) 00:12:19
>>599
C99にはinlineがある
現在でも(C99対応してなくても)主要なコンパイラはほぼ対応済み

602 :デフォルトの名無しさん:2008/10/06(月) 00:21:10
>>600
スーパーセットをマイナス方向にしか考えないのか?
C++はマクロの問題を解決できる機能をいくつか追加している。
inline, template, namespace など。

603 :デフォルトの名無しさん:2008/10/06(月) 00:35:10
templatewwwwwwwwwwwwwwwww
マクロの問題の100倍以上大問題な機能ですねwwwwww

604 :デフォルトの名無しさん:2008/10/06(月) 00:37:25
東京から品川へ行くのに新幹線を使う様なもんだな

605 :デフォルトの名無しさん:2008/10/06(月) 00:45:58
>>602
いや、むしろ逆でしょ
擁護派が都合の良い時だけスーパーセットを主張してるみたいだから
都合の悪い部分もちゃんと継承しろって言ってるだけ

大体さ>>591が言うような
>ひどいときは小文字1文字のマクロがあって原因の特定に時間がかかる。
↑みたいな奴がC言語の問題点として挙がってるけどさ、
そいつはC++使ったって小文字1文字のマクロを定義するでしょw
むしろC++ならもっと素敵な大惨事になりそうだと思わない?

606 :デフォルトの名無しさん:2008/10/06(月) 00:49:08
マクロといえば誰もが知ってるのがmin/max問題だろう

607 :デフォルトの名無しさん:2008/10/06(月) 00:49:58
>>600に対して>>602のレスって・・
C++擁護派は都合の悪い意見はわざと間違った解釈で話題を逸らそうとしてるように見える
それとも本当に理解出来ないほど頭が悪いのか?

608 :デフォルトの名無しさん:2008/10/06(月) 00:50:12
>>596
だからお前にとって良くないだけで、お前が使わなきゃいいだけ。
Swingでぐだぐだなアプリでも作ってろって。
C++みたいな技術者としての基本スキルが扱えないワンランク下の技術者と
して生きていけばいいだろ。

609 :デフォルトの名無しさん:2008/10/06(月) 01:01:01
他人の書いたコードはどうしようもないし、
605の「そいつはC++使ったって小文字1文字のマクロを定義するでしょw」も絶対に間違いない。

だけど、少なくとも自分の書く部分ではC++の機能でマクロを回避できば、
その分マクロの問題に遭遇する可能性は低くなるはず。
もちろん、使い込むとそっちの機能で問題に出食わす羽目になるが。

610 :デフォルトの名無しさん:2008/10/06(月) 01:13:15
小文字1文字のマクロを定義する奴なんかにC++使わせたら
何気なく足し算する時も「もしかしてこのoperator+引き算してんじゃねえだろうな」って
いちいち怯えながら使わなきゃならなくなるじゃねえか

611 :デフォルトの名無しさん:2008/10/06(月) 01:18:22
C++アンチは些細な問題を避けるためにどんだけ利便性捨てているんだよ。

612 :デフォルトの名無しさん:2008/10/06(月) 01:23:56
マクロ云々はどうでもいいが
ABIの問題などは、本来低レベルの道具作りにはずのC++としてはちっとも
些細な問題じゃない

だからMSはCOMみたいな物を作ったが
COMは結局糞だったので.NETにとってかわりつつある
.NETの提供する相互運用性を横目に、C++は、自分に閉じたテンプレートの
世界だけで生きて行こうとしているわけだな

613 :デフォルトの名無しさん:2008/10/06(月) 01:25:39
>>608
C++ への批判を "C++ を使えない" という話に都合良くすり替えるなよw
それに、"C++ は難しい" という前提で話すのもそろそろ止めようぜ
Perl と同じで汚いだけなんだから

614 :デフォルトの名無しさん:2008/10/06(月) 01:32:47
一部の狂信者がアンチはC++理解出来ないことにしたがってるのが萎える
このスレを見る限りアンチはC++を理解した上で批判してる
擁護派のひとは的外れでないC++の批判や問題点はきちんと受け止めよう
それで利点欠点を天秤に載せてC++を使う使わないの判断は勝手にすればいい

615 :デフォルトの名無しさん:2008/10/06(月) 02:00:03
お互い考え方が違うんだから、お互い論理的な説明をしても話がかみ合わないのは当然。

616 :デフォルトの名無しさん:2008/10/06(月) 02:11:08
そもそも嫌いならだまって使わなきゃいいだけなのに、基地外C++アンチが粘着してる
ように見えるけど。

617 :デフォルトの名無しさん:2008/10/06(月) 02:12:05
スレタイ読めよ

618 :デフォルトの名無しさん:2008/10/06(月) 02:22:23
ここは不可避で理不尽な思いをした職業プログラマの愚痴履き場

自称ワカッテル趣味プログラマの反論は、その面から見るととても低レベルで糞の役にも立たない妄言しかない

ま、経験した事無いんだから想定できなかったとしても馬鹿とまでは言わないよ
ただ、その自己陶酔した妄言と違って「現実に起こっている事」なんだという事くらいは覚えておいて欲しい

619 :デフォルトの名無しさん:2008/10/06(月) 03:01:15
>>615
あきらかに擁護派の方が非論理的なレスが多い、
アンチが化けてるのかってぐらい擁護派はおかしい。
何度も指摘されてるし、スレ読み直すと一目瞭然だよ。

620 :デフォルトの名無しさん:2008/10/06(月) 03:22:53
lambdaとかmplとか1文字マクロとか現状のコードではほとんど問題にならないような
ものを取り上げた批判が論理的には感じないけどね。
C++はCとの互換性とか、ゲームからデスクトップアプリから組み込みから科学技術
計算まで想定してる汎用言語だし、歴史も長いから情報量も膨大だし、自分に必要な
ものだけを上手に取捨選択できる経験値が求められるのは確かだし、そういう意味で
難易度が高いと思うよ。

621 :デフォルトの名無しさん:2008/10/06(月) 08:02:28
自分に必要なものの判断なんて別に難しくないし、そんなこと非論理的な擁護派意外誰も論じてない。

難しいのは知りもしない他人が必要としたものの判断。
C++ではこれが壊滅的に終わってる。

622 :デフォルトの名無しさん:2008/10/06(月) 08:41:21
なんか頭悪そう

623 :デフォルトの名無しさん:2008/10/06(月) 10:22:58
とりあえず、頭悪い奴にC++を扱うのが無理だということだけは分かるw

624 :デフォルトの名無しさん:2008/10/06(月) 11:13:26
>>620
ABIの問題とか色々まともな批判も出てるだろ
見たくないものには目をつぶってどうでもいい批判しかないと
片付けたがっているようにしか見えんよ

625 :デフォルトの名無しさん:2008/10/06(月) 11:30:38
C++の代わりに何を使えばいいというのだろう。

626 :デフォルトの名無しさん:2008/10/06(月) 11:48:17
初心者がやたらポインタ使いまくる症状になんか似てね?


今の時代、絵を描くのだって、いくらだって大きな紙は用意できるけど
だからって欲張って全部使おうとする事はないと思う・・・
ハサミというものを用意してちょっとずつ切って使えばいいんだよ!
人が作ったものを人が使いこなせないってことが、今リアルにC++で起こってる

627 :デフォルトの名無しさん:2008/10/06(月) 12:07:16
Dに注目が集まったのはC++への不満の裏返しだな
まあDはDで別の理由でポシャったけどな

628 :デフォルトの名無しさん:2008/10/06(月) 12:14:14
JavaもC++を否定して注目集めた

629 :デフォルトの名無しさん:2008/10/06(月) 12:18:15
とりあえず、自分の意見は論理的って思い込みを捨てるんだ
ここまでで論理的な意見なんて一個も出てないからww

630 :デフォルトの名無しさん:2008/10/06(月) 12:22:45
>>628
Javaはサーバーサイドアプリケーションの分野ではC++を追い落としたな
それだけだが

631 :デフォルトの名無しさん:2008/10/06(月) 12:25:08
C#ぐらいの言語仕様&開発環境の成熟度で
Delphiのようにネイティブコンパイル&スタティックリンク可能な環境があれば
いいんだがな

632 :デフォルトの名無しさん:2008/10/06(月) 12:53:12
>>624
> 見たくないものには目をつぶって
>>619みたいな人のことですね。

633 :デフォルトの名無しさん:2008/10/06(月) 12:58:09
>>619
本当に何度もそんなことが「指摘されてる」なら、それってつまり、
一方的で自分に都合のいい「指摘」を何度もするのが、このスレの否定派ってことだよね。
「俺よりアイツのほうが明らかに馬鹿」って言う、あまりに幼稚で痛々しい意見を、
擁護派より否定派のほうがたくさんしてるっていう証言だよね、これ。

自爆してない?

634 :デフォルトの名無しさん:2008/10/06(月) 13:10:08
>>631
つcrossnet

635 :デフォルトの名無しさん:2008/10/06(月) 13:15:44
例えばさ、近いところだと
>>590 >>591 >>600 >>602 >>605
ちょっと長いけどこの流れ見てどう思う?
どうみたっておかしいよね?

636 :デフォルトの名無しさん:2008/10/06(月) 13:21:02
しかもそれに対して>>620ではさらに
>lambdaとかmplとか1文字マクロとか現状のコードではほとんど問題にならないような
ものを取り上げた批判が論理的には感じないけどね。
これもありえない
擁護派はこの手のすり替えとかごまかしが多いって言われてるわけだ

637 :デフォルトの名無しさん:2008/10/06(月) 14:35:27
C++は言語屋やハッカーからは大抵嫌われている
という印象を持っているんだが、偏見かね

C++は仕方なく我慢して使う言語、だと思っている

638 :デフォルトの名無しさん:2008/10/06(月) 15:31:57
言語屋は現実より理想を求めるので C++ が嫌いなのが多いと思う。禿も言語屋の意見は二の次にしている。
ハッカーはいろんなのがいるから分からない。

仕方なく我慢して使うような言語なら自然と消えていくだろう。
OS と違って言語は開発側が選択しやすいんだから。

639 :デフォルトの名無しさん:2008/10/06(月) 15:43:03
ハッカーにとってみればメモリの実際の内容が気になるだけだから
いちいちコンパイラに文句言われてreinterpret_castとか書くのが面倒になるんじゃないかな。

ところで否定派は「バカが書いたライブラリや同僚のバカが書いたコードに
煩わされるから&その上、上からC++使えと強制されるから」
とかそういう理由で嫌ってる人が多いような気がするんだが。
C++を嘆くよりその会社を辞めることをお勧めしたい。
そもそもC/C++はプログラマを信用して、誤用よりも利便性を優先してるんだから
バカに書かせたらダメなんだと何回言わせr(ry

640 :デフォルトの名無しさん:2008/10/06(月) 15:56:29
>>638
> 仕方なく我慢して使うような言語なら自然と消えていくだろう。
> OS と違って言語は開発側が選択しやすいんだから。

そうでもないだろ
現在の主流OSはLispシステムでもJava OSでもなく
Cをベースにしているのがほとんどだから、それらのOSでは
C系の言語は特権的な地位を占めることになる

Cとの互換性は、C++を広める上では一番の強みであり、
同時に言語の中身だけ考えれば最大のネックにもなっている

641 :デフォルトの名無しさん:2008/10/06(月) 18:47:47
擁護派は>>638みたいな意見を見てもおかしいと思えないの?そんな馬鹿なの?

642 :デフォルトの名無しさん:2008/10/06(月) 18:56:12
>>630
携帯のアプリも

643 :デフォルトの名無しさん:2008/10/06(月) 19:02:26
C++を嘆くよりその会社を辞めることをお勧めしたい。(キリッ

644 :デフォルトの名無しさん:2008/10/06(月) 19:08:31
> バカが書いたライブラリや同僚のバカが書いたコードに煩わされるから

実際C++は馬鹿避け仕様多いよな

もっとも、型付けだけ強くても、型推論してくれるわけでもねーし
JavaやC#ほどインテリセンス向きでもねーし
テンプレートを使えばコンパイルエラーはあっさりゲシュタルト崩壊するし
reinterpret_castとか長々とタイプさせたところで
相変わらずC++で自分の足を撃つのはこれ以上ないぐらい簡単なんだけどな

645 :デフォルトの名無しさん:2008/10/06(月) 19:26:37
>>641
世界中の言語屋より禿一人が正しいと思ってるんだから仕方が無い
信者というのはそういうものだ

646 :デフォルトの名無しさん:2008/10/06(月) 19:39:08
gccとテンプレートは分けて使うことにしたらいい。
またはgccを使わない。
あら不思議、C++がとっても素敵な言語に。

647 :デフォルトの名無しさん:2008/10/06(月) 20:00:43
逆に言えば、新しい言語を作ったとしてどの言語で実装する?

648 :デフォルトの名無しさん:2008/10/06(月) 20:06:35
>>638
逆に、今でもC++は消えていないということは、
仕方なく我慢して使うような言語ではないとも言える。
>>630>>642が挙げたように消えたところもあるし、今現在消えつつある分野もまた。

>>646
GCC以外も同じくらいだめだめだと思う。

>>647
Cじゃね?

649 :デフォルトの名無しさん:2008/10/06(月) 20:22:53
VCとか6時代に比べりゃ格段にマシにはなってるんじゃね
Dinkumwareは相変わらずっぽいし
セキュアCRT絡みがなにげにウゼーけどな

650 :デフォルトの名無しさん:2008/10/06(月) 20:46:44
C++ が消えていないのは、商用のコンパイラが整備されているとか、
ライブラリが沢山あるとか、ネイティブに落とせてそれなりの速度が
出るとか、機能をつまんで使うならそこそこ便利だとか、C と互換性が
ある程度考慮されているとか、まぁ色々理由があるよね。

C++ に消えてもらいたい理由もごまんとあるけど、代わりの言語を
提示するのは中々難しい。既に Java で置き換えられた分野もあるけど、
D とか ObjC とかはまだまだだよね。C + LL とかが最有力候補かな。
最近は C++ + LL とかもあるから安心出来ない。

651 :デフォルトの名無しさん:2008/10/06(月) 20:53:52
うちの会社はみんなうれしそうに C++ 使っているぞ。
顧客から無理やり C 使わせられたときはみんなブーブー文句言っているぞ。

652 :デフォルトの名無しさん:2008/10/06(月) 21:02:36
>>651
なんか可愛いなw

653 :デフォルトの名無しさん:2008/10/06(月) 21:16:07
「擁護派」でレス抽出すると粘着がいることがよく分かる。

C++に醜い部分があるのは確かだが、
後発の方がきれいなのは当たり前だろう。
Dでマングリングが統一されているのはイイと思うけど、
マイナーすぎて実用する気にはならないね。

654 :デフォルトの名無しさん:2008/10/06(月) 21:19:02
マングリングとか小学校で教えられないだろ
用語選べよな…

655 :デフォルトの名無しさん:2008/10/06(月) 21:20:42
名前がエロい

656 :デフォルトの名無しさん:2008/10/06(月) 21:22:54
そうなんだよなあ。C++ は醜い。出来れば使いたくないもんだ。
演算子のオーバーロードなんて無い方がスッキリする。

657 :デフォルトの名無しさん:2008/10/06(月) 21:43:58
VC8SP1はDinkumwareが気に入らないんだが、かと言ってtr1を標準装備
したので今更STLportに戻る気も起きないし・・

658 :デフォルトの名無しさん:2008/10/06(月) 21:48:33
VC9の話かな?
Dinkumwareは糞だと分かっててももういいやって感じだな
boost他とのからみもあるし

_SECURE_SCLってみんな切ってるのかね?


659 :デフォルトの名無しさん:2008/10/06(月) 21:53:04
>>656
いや、演算子の多重定義は要る。C++のは改良の余地がありまくりだが。

660 :デフォルトの名無しさん:2008/10/06(月) 21:54:17
>>658
あ、ごめんなさい
VC9SP1でした。

661 :デフォルトの名無しさん:2008/10/06(月) 22:35:26
演算子のオーバーロード嫌がるのってJavaの人くらいかと思ってるんだが違うのかな
オーバーロード可能な言語どころか追加定義できる言語もあるわけで

あとテンプレート悪玉論唱えてる人は簡単なアプリでもいちいち自前で各型向けのlistとか作ってるの?
どうしてる?

662 :デフォルトの名無しさん:2008/10/06(月) 22:52:54
>>661
そういうことを主張する人は、そもそも動的型付けか何かで
テンプレートがなくても問題ない言語を使っているんだろう。

663 :デフォルトの名無しさん:2008/10/06(月) 23:02:11
たんなる総称型なら持っている言語は多いとは思うが
C++のテンプレートとは別モンじゃないか?
C#やJavaのGenericsも違うしな

664 :デフォルトの名無しさん:2008/10/06(月) 23:06:11
>>663
日本語読めないの?

665 :デフォルトの名無しさん:2008/10/06(月) 23:06:40
コンセプトをインターフェースにすればいいだけだろ。

666 :デフォルトの名無しさん:2008/10/07(火) 00:12:49
テンプレートが悪いって言ってる人間はテンプレート全く使ってないと思ってるの?

667 :デフォルトの名無しさん:2008/10/07(火) 00:25:20
coutとかstringとか
ありふれた道具の裏にことごとく潜んでるサブプライムローンみたいな存在ですから

668 :デフォルトの名無しさん:2008/10/07(火) 01:07:56
>>659
Lisp とか Smalltalk みたいに、関数と演算子の区別が無い言語なら何やっても良いよ。
C++ みたいな言語に入れるのは間違いの元だと思われ。

669 :デフォルトの名無しさん:2008/10/07(火) 01:12:55
STL, boost, 自分で作ったテンプレートも特に問題なく便利に使えてるんだから
テンプレートに問題があってもかまわない。演算子も。

670 :デフォルトの名無しさん:2008/10/07(火) 01:15:04
&&と||のオーバーロード許可してるのは明らかな設計ミスだろ
遅延評価持ってないくせに

671 :デフォルトの名無しさん:2008/10/07(火) 01:17:07
そういう人間とチームで開発すると苦労しそうだから嫌というか不安。
C++ だと最初にルールを決めても破綻しそうだな。

672 :デフォルトの名無しさん:2008/10/07(火) 01:19:00
お、済まん。>>671>>669 向けね。

673 :デフォルトの名無しさん:2008/10/07(火) 01:27:25
>>666
嫌なら使うなよ

674 :デフォルトの名無しさん:2008/10/07(火) 01:40:58
ぶっちゃけるとテンプレートの問題より>>669みたいな奴が開発に関わる事の方が問題がある

675 :デフォルトの名無しさん:2008/10/07(火) 01:51:50
C++は問題があるから使わないってやつはどれほどチーム開発で試してきたんだよ。
C,C++は仕事でそれぞれ20,15年ぐらい使ってきが、ここ5年ぐらいC++特有の問題は
たいして起きていないぞ。けして優秀な人間ばかり揃えているわけではない。
新卒でいきなりC++使わせているけどそれほどひどい使い方はしていないよ。
むしろCで作らせたほうが間違いが多いぞ。

676 :デフォルトの名無しさん:2008/10/07(火) 01:54:21
テンプレートやらオーバーロードやらを自由に使わせてそれなら
相当優秀な人間が揃ってるか、問題を認識できないボンクラばかりかのどっちかだな

677 :デフォルトの名無しさん:2008/10/07(火) 01:55:57
>>670
Lispで言ったらspecial formとprocedureをごっちゃにしてるようなもんだよな
かなり笑える話だ

678 :デフォルトの名無しさん:2008/10/07(火) 02:17:43
LispはC++の代わりにならないからな。

679 :デフォルトの名無しさん:2008/10/07(火) 02:20:30
>>678
意味分かんないで反応してるだろ

関数呼び出しが引数を全部先に評価しちまう正格評価のくせに
&&や||を関数にしちまうなんてのは、
情報系の学部学生でもやらないレベルの誤りだろ

680 :デフォルトの名無しさん:2008/10/07(火) 02:23:38
なんでC++は難しいって事になって
C++を悪く言う奴はC++を使ってない(使えない)って事になってるんだ?

いや、そこまで強烈に決め付けできる幸せな脳みそだからC++使ってて幸せなのか^^;

681 :デフォルトの名無しさん:2008/10/07(火) 02:37:49
C++は完璧でこの世で最も優れた言語なんだ!!!!
C++に欠点なんか無い!!
だからC++を悪く言う奴はC++を理解出来ないに違いない!!!!
って考えてるからだよ^^

682 :デフォルトの名無しさん:2008/10/07(火) 04:24:22
あんまりレベルが違い過ぎると、合わせるのに疲れ果ててしまうのがC++の厄介なところ。

683 :デフォルトの名無しさん:2008/10/07(火) 04:32:49
>>679
何を問題にしてるのかさっぱり分からないのは確かだけどな。

684 :デフォルトの名無しさん:2008/10/07(火) 04:43:10
operator&&を組み込みの&&演算子と同じ挙動にすることは絶対に出来ないんだぞ
ひどい話だろ

685 :デフォルトの名無しさん:2008/10/07(火) 04:48:59
前10レス読んだだけの脊髄反射レスだけど
万全でなければ使えないようにするというのも、またどうかとも思うけどね
論理演算子でトラブッた事はない訳で
コードする側が保障する必要のあるものは、便利にする過程でどうやっても登場するよ。
これらはテストツールの充実で解決して欲しいね。

686 :デフォルトの名無しさん:2008/10/07(火) 04:50:01
あ゛ーC++にテストツールとか無茶もいい所か・・・
スレタイ読まずでした

687 :デフォルトの名無しさん:2008/10/07(火) 05:16:10
>>684
More Effective C++に書いてあるね

688 :デフォルトの名無しさん:2008/10/07(火) 08:41:14
>>684
誰も使ってない部分の話はどうでもいい

689 :デフォルトの名無しさん:2008/10/07(火) 08:51:14
中途半端な使用を放置してる事は問題なのに、どうでもいいとか問題無いとか…
問題を見てない振りしてるくせに、使ってない奴はレベルが低いとか…

690 :デフォルトの名無しさん:2008/10/07(火) 08:53:38
使用→仕様、ね。変換ミスした。

691 :デフォルトの名無しさん:2008/10/07(火) 09:00:20
>>689
で、問題になったことは?
多重継承のがずっと問題あるのに全く話題にあがらないのが不思議なんだけど

本質を突かない話なんか本当にどうでもいい

692 :デフォルトの名無しさん:2008/10/07(火) 09:03:39
そんなの本質じゃないごっこはどうでもいいけど、
問題を上げればきりが無いのが C++ だな。

693 :デフォルトの名無しさん:2008/10/07(火) 09:06:16
>>692
素直にこれ豆知識なって書いておけばよかったのに
顔真っ赤かよww

694 :デフォルトの名無しさん:2008/10/07(火) 09:07:29
問題があるから使わないのに、俺は問題と認識してないからと
突っ走る奴が居るのが問題なんだよな…

695 :デフォルトの名無しさん:2008/10/07(火) 09:14:44
>>693
どう見ても君の顔が真っ赤だし、なんか歯軋りとかも聞こえますよ。
打鍵の音もなんか凄そうですw

696 :デフォルトの名無しさん:2008/10/07(火) 09:17:29
突っ走るって何のこと?
誰も使ってない(=使うことではない)のだから…うん?

抽象的な表現に逃げられると途端に意味がわからん

俺はこんな仕様知ってるんだぜ大会ではないんだぜだぜ

697 :デフォルトの名無しさん:2008/10/07(火) 09:21:32
>>695
怒った時の君の顔が浮かんだ
普通の人は頭に血がのぼっても歯ぎしりなんかしない

698 :デフォルトの名無しさん:2008/10/07(火) 09:22:47
>>695はもうキーボードの前にいるのか
仕事しろw

699 :デフォルトの名無しさん:2008/10/07(火) 10:16:33
なんか校則がギッチギチのDQN学校の生徒が、
校則ゆるゆるの進学校に対して、お前のところはルールがゆるすぎるから学校の治安が悪くなるって喚いてるイメージw

700 :デフォルトの名無しさん:2008/10/07(火) 10:26:45
>>683
int i=0;
if (i++ || i++) {
printf("%d", i);
}



701 :デフォルトの名無しさん:2008/10/07(火) 11:27:57
落とし穴だらけでもはや正格評価で&&や||を関数化することの問題すら
C++信者には見えなくなってるのか

以下のようなif文がある
if (expr) statement
exprを評価して真の場合にだけstatementを評価する
常識だな

これを
if(expr, statement)
という関数にすることを考える

C++は多くの言語と同様正格評価だから、if関数を評価する前に
expr, statementの両方を評価することになるが、
言うまでも無くこの時点で元のif文とは意味が異なっていることになる

&&や||も全く同じだ
これらはショートサーキットだから、本来右オペランドは条件付きでしか
評価されない
C/C++のコーディングではその性質が多用されるが、関数化されていれば
常に評価されてしまう

禿は、無用で、使えば問題を引き起こすと分かっているこの機能を
平然と取り入れ、仕方が無いからC++ユーザはそれを避けることで
問題を回避する
些細に見えるかもしれないが、このようなものが積もりに積もって、
結果としてC++は糞の山になっているんだぞ

702 :デフォルトの名無しさん:2008/10/07(火) 11:32:25
誰も見えてなくないじゃん。 使わないからどーでもいい、って言ってる。
んなこと言い出したらCだって過去の負の遺産が大量に残っているが。

703 :デフォルトの名無しさん:2008/10/07(火) 11:35:17
>>702
「お前は」どうでもいいかもしれないが「言語としては」どうでもよくないんだよ

実装者にはその無用なものを実装するコストがかかり
教育者にはその無用なものを使ってはいけないと教えるコストがかかり
学習者にはその無用なものを使わないように学ぶコストがかかり
ユーザにはどこかの馬鹿が罠にはまったかどうかをチェックするコストがかかる

704 :デフォルトの名無しさん:2008/10/07(火) 11:37:37
> Cだって過去の負の遺産が大量に残っているが
墓穴だな

C++はCとの互換性のために、その負の遺産を全て引き継いだ上で
比較にもならないほど多くの落とし穴を自分で掘っているのだから

705 :デフォルトの名無しさん:2008/10/07(火) 12:54:10
まぁ、批判するにも代替手段を提示して欲しいわなw
畢竟どの言語もみんなしょうがなく使ってるわけだしw

706 :デフォルトの名無しさん:2008/10/07(火) 13:11:11
細かいところまで見たらウンコな仕様があるのはどの言語もだいたい一緒だと思うぞ

Javaだってウンコだらけだし

707 :デフォルトの名無しさん:2008/10/07(火) 13:24:32
問題はC++のうんこは臭すぎることなんだよね
形は整ってるかもしれないけど飛び散りすぎてるし

708 :デフォルトの名無しさん:2008/10/07(火) 13:33:29
そもそもCが糞なんだから、C++が糞なのは自明。


709 :デフォルトの名無しさん:2008/10/07(火) 14:38:21
>>705
なんで代替手段を提示する必要があるわけ?
言語の批判は批判でいいじゃん
それと他の言語が糞だからってのも関係が無い

710 :デフォルトの名無しさん:2008/10/07(火) 15:54:05
C++が糞言語でないと気がすまないらしいな。

711 :デフォルトの名無しさん:2008/10/07(火) 15:59:52
>>709
結局のところ、みんなC++は糞だと思いつつも、ほかの言語はさらに糞なので
一番まともで最高なC++を使ってるわけだよ。
で、もっといい言語があるなら乗り換えたい。
しかし、そんなものはないので仕方なくC++を使ってるわけさ。
そういう状況下で、「C++は糞」とか主張しても「で、もっといい言語あるの?」
って聞き返されるのは当然でしょ。
関数型言語にはものすごい期待したんだけど、使ってよかったと思える状況って
CGIとか程度じゃない?
CUI全盛の時代だったらいっぱい使い道あったんだろうけどね。
結局、糞だ糞だと思いつつもC++を使うしかないわけ。
だって今ある中では最高の言語だからね。

で、もっといい言語あるの?

712 :デフォルトの名無しさん:2008/10/07(火) 16:01:08
ひどい釣りだな

713 :デフォルトの名無しさん:2008/10/07(火) 16:05:51
>「で、もっといい言語あるの?」
>って聞き返されるのは当然でしょ。
用途もなにも前提なしで「いい言語あるの?」と聞き返すのは
そりゃ莫迦にとっては当然かも知らんが。

714 :デフォルトの名無しさん:2008/10/07(火) 16:07:38
>>713
だってC++は用途を問わず最高の言語だからね。
CGIを書くには最適ですっていう言語があったとしても代替にはならないでしょ。
そう思わない?

715 :デフォルトの名無しさん:2008/10/07(火) 16:12:56
換言すれば、C++で出来ることは全てカバーしていなければ代替にならない。

で、もっといい言語あるの?

716 :デフォルトの名無しさん:2008/10/07(火) 16:14:30
釣りもいいけどageないで欲しいな

717 :デフォルトの名無しさん:2008/10/07(火) 17:01:55
>>694
突っ走るって、現実に&&や||を定義するやついるのか?Boost.Lambdaくらいしか知らないが。
.や.*と同じようにこれも禁止しなかったのは間違いだと俺も思うが。

>>705
C#のture/false演算子はC++の&& ||よりましだと思う。

718 :デフォルトの名無しさん:2008/10/07(火) 17:35:54
禁止するよりも力尽くでも本物と同じ動きに出来るようにするべきだった。

719 :デフォルトの名無しさん:2008/10/07(火) 17:45:32
ageている奴は発言が面白すぎるので愉快犯と見た

&&はテンプレートの中で型が確定できない状況で使ったらセマンティクスが
全く不明になってしまうね
それはショートサーキット評価されるのだろうか、されないのだろうか?

720 :デフォルトの名無しさん:2008/10/07(火) 18:09:15
>>701
言いたいことは判るけどさ、それで問題が起こるようなケースってのは
コピーやキャストされてしまうような時だけであって、そうなるかもしれないってのが頭にあるなら
できる限り避けましょうと、参照にしたりすればよく、逆に高速化が必要ならオーバーロードしたりテンプレート化したりして個別対応すればいい訳。
実用上の障害は何一つないのに問題視するのは、それ自体問題だ。

721 :デフォルトの名無しさん:2008/10/07(火) 18:14:02
>>719
テンプレートはコンパイル時に型が特定されるので、問題はないのでは?
動的なテンプレートを実装したりすると問題が起こると思うけどC++はそうではないし。

722 :デフォルトの名無しさん:2008/10/07(火) 18:17:41
>>721
勿論テンプレートを実体化するときには確定するな
が、テンプレートは静的ダックタイピングの手段だから、
関数テンプレートを記述する際には型に関する仮定はおけんだろ?
で、&&はどうすりゃいいんだろうな
&&が腐ってるんなら、仕方なくVBみたいにifのネストを使うか?

723 :デフォルトの名無しさん:2008/10/07(火) 18:20:36
C++最大の問題はプリプロセッサと旧態依然のコンパイル・リンクだろうな、あれの存在のお陰で
自動テストは作れない作ってもショボイ、インテリセンスも作れない作ってもバカの極み
自動リファクタリングに至ってはもはや絶望的、しかもコンパイルもリンクも超低速という点。

724 :デフォルトの名無しさん:2008/10/07(火) 18:35:14
>>722
それが問題になるような事態に直面した事はないが、仮に直面してどうしても困るなら
type_traits でも使えばよいのではと俺なんかは思ってしまいます。

725 :デフォルトの名無しさん:2008/10/07(火) 18:41:57
>>724
議論ずれてきてるな
こんな風にすればカバーできるよ!ってのどんどん突き進めたのが
TMPなりboostなりだろ

いやそれはあんたはそれでいいのかもしれねーけどよ
大したことやってるわけでもねーのに、あの糞ったれなバッドノウハウ集
全部押し付けんのか?プログラマに

&&の問題なんて、禿の設計誤りさえなければそもそもそんなことを
考える必要すらないんだぜ

726 :デフォルトの名無しさん:2008/10/07(火) 18:43:26
>>725
それ以前に困った事態ってのはどんな事態なんだよ、俺はそっちの方が気になる。

727 :デフォルトの名無しさん:2008/10/07(火) 18:46:53
>>726
俺は困ってねえよ
ユーザ定義&&なんてつかわねえからな
自分では

が、テンプレート関数の中の&&は、一種の時限爆弾のようなもんだろ
誰かがユーザ定義&&を用いたら、それはコンパイルエラーにはならず
不可解な実行時の問題を引き起こす、かもしれない
そして、それはすぐには気づかれない、かもしれないわけだ

728 :デフォルトの名無しさん:2008/10/07(火) 18:50:27
それが心配でたまらないなら、ある種病気だよ

729 :デフォルトの名無しさん:2008/10/07(火) 18:53:03
実際、「C++の仕様で爆弾発生率が高い」ってのがソースなさすぎだからなw

730 :デフォルトの名無しさん:2008/10/07(火) 18:54:32
流石にそれはないよw
ただ、俺はそういう問題を知るためにまたしても*無駄な*コストを払わされたがな

みんな麻痺してんじゃねえのか?
C++の要求するあまりの学習コストの高さとバッドノウハウの多さに
確かにこんなのは氷山の一角ですらねえよ
もともとが糞の山過ぎてな


731 :デフォルトの名無しさん:2008/10/07(火) 18:57:11
危険だと分かっているものであれば自然、用心深く取り扱われるので、思ったほど事故は起こらないもの。
面倒臭いだけだから何とかしろとは思うが、それらの問題点に突っ込み入れても問題は出てこないだろうね。
C++逝ってよし派ではあるんですが、重箱の隅をつつくような問題点指摘には賛成できない。

732 :デフォルトの名無しさん:2008/10/07(火) 18:57:54
お金もらえるならなんでも書くよ

733 :デフォルトの名無しさん:2008/10/07(火) 19:08:41
>>727
まあ、もしそういうことが起こったら、&&を定義したユーザの方が悪いだろということにされるな。
やっぱりなんでこんなの定義できるようにしたんだって話ではあるが。

734 :デフォルトの名無しさん:2008/10/07(火) 19:15:29
ヘッダファイルに
static int int_data;
#define x int_data
などと比べれば&&など些細な問題さ


735 :デフォルトの名無しさん:2008/10/07(火) 20:21:24
&&と||は避けようと思えば避けられた問題だもん
演算子はとにかく全部オーバーロードできるというわかりやすい規則を優先して
その中には危険な演算子もありますよという話ならまだわかる
でもそうじゃないじゃん
例えば&&と同じく副作用完了点を持つ?:はオーバーロードできない
::は出来ないし.も.*も出来ない、sizeofもtypeidもthrowも出来ない
どれも問題あるからわざと出来ないようにしてるんだ
どうしてこのリストの中に&&と||を加えることが出来なかったんだ?
つーか?:を出来なくした時に気付けよ禿

736 :デフォルトの名無しさん:2008/10/07(火) 20:42:31
えんざんしちげーだろ

737 :デフォルトの名無しさん:2008/10/07(火) 20:44:22
そんなに気になるなら、&&セーフとか&&FREEのシールでも貼っとけ。

738 :デフォルトの名無しさん:2008/10/07(火) 20:51:51
>>729
>実際、「C++の仕様で爆弾発生率が高い」ってのがソースなさすぎだからなw
EffectiveC++等々の存在は十分爆弾発生率の高さを証明してると思うが・・

739 :デフォルトの名無しさん:2008/10/07(火) 21:00:38
EffectiveJavaもあって、初級者用じゃないけどJavaプログラマの中ではかなりの必読の部類に入るよ。

740 :デフォルトの名無しさん:2008/10/07(火) 21:16:14
組み込み系の経験ないんですが、C++使用の場合って
コーディング規約とかで縛ったりするものなんでしょうか?

741 :デフォルトの名無しさん:2008/10/07(火) 21:18:14
もう一つ問題がある演算子があって、それはカンマ演算子
&&や||などと同じく、やはり副作用完了点として働く演算子の一つだ
普通は逐次実行されるので、左辺も右辺もどのみち評価されるから気にすることは少ないが
左辺が例外投げるような場合はやはり同じような問題が起こる

さて、なぜoperator,は定義できてしまうのか?偉大なるBjarne大先生の答えはこうだ

>operator,をオーバーロードできるようにしたのは、そうしてはいけない理由がなかったからだ。
(C++信者の聖典、D&Eより引用)

これはひどいwwwwwwwww

742 :デフォルトの名無しさん:2008/10/07(火) 21:19:58
ある分野では operator , が実用上離せない

743 :デフォルトの名無しさん:2008/10/07(火) 21:25:34
>>739
それ関係なくね?

744 :デフォルトの名無しさん:2008/10/07(火) 21:31:32
>>741
なんつうかおじいちゃんはもっといたわって隠居させるべきだと
思ってしまうな

745 :デフォルトの名無しさん:2008/10/07(火) 22:05:12
いけなかったというより、::や.のような制約がなかったからと言うべきのような……。

746 :デフォルトの名無しさん:2008/10/07(火) 23:54:42
>>727
核戦争の心配してるほうがお似合い
そっちのほうが被害は甚大だし現実にあり得る

747 :デフォルトの名無しさん:2008/10/08(水) 00:11:43
結局、使いこなせない人が「この要素が悪いんだボクが悪いんじゃないやい」
って言い訳しつつ、使いこなせる人をデタラメに煽って射精するスレってことでおk?

748 :デフォルトの名無しさん:2008/10/08(水) 00:21:39
operator&&なんて使いこなしちゃいけない機能です

749 :デフォルトの名無しさん:2008/10/08(水) 00:25:31
問題点を指摘されて、それがありえる・ありえないって話にすり替えるのは違うんじゃないか
問題はあるけど回避可能だからC++を使おうって判断はそれぞれの職場でやればいい
だけどココで問題を指摘されてるのに、自分にとってありえないから問題じゃないってのはお話にならないよ

750 :デフォルトの名無しさん:2008/10/08(水) 00:33:41
>>747
また同じ煽りパターンか
ぼくちんのC++に文句いうやつらは全員C++理解できないに違いない!
C++も禿もぼくちんも天才!欠点なんかあるわけない!
これで満足?

751 :デフォルトの名無しさん:2008/10/08(水) 00:36:09
何でもルールのせいにするのはゆとりだろう。

752 :デフォルトの名無しさん:2008/10/08(水) 00:40:30
C++ しか知らなければ、C++ を過大評価したくもなるんじゃないかな。
2ch で主張してる分には見掛け上はノーリスクだし。

753 :デフォルトの名無しさん:2008/10/08(水) 00:54:36
747みたいに突然流れ無視して
「アンチはC++使いこなせないんだ!」って暴れ出す厨が定期的に出てくるよな
正直、どっちサイドからみても邪魔な基地外なんだがw

754 :デフォルトの名無しさん:2008/10/08(水) 01:02:39
テンプレートメタプログラミング禁止とか多重継承禁止とか
実際に実行出来てる例はあるのかな。ベターCとして使う事を
考えるなら当たり前に出来て欲しいんだけど、どうも揉めそうだ。
他にも例外禁止とか名前空間禁止とか演算子のオーバーロード
禁止とか、Boost禁止とか、RTTI禁止とか。

755 :デフォルトの名無しさん:2008/10/08(水) 01:15:19
>>750
君って低学歴でしょ?

756 :デフォルトの名無しさん:2008/10/08(水) 01:31:45
>>754
禁止する理由を納得のいくように説明すれば揉めないんじゃない。

757 :デフォルトの名無しさん:2008/10/08(水) 01:49:11
>>749
&&なんてC++使っているほうからしたら、誰も使わないだろjkって話なんだが、
外から見たら、ようするにバッドノウハウなんだよな。
そこに温度差というか埋まらない溝を感じた。

758 :デフォルトの名無しさん:2008/10/08(水) 01:55:05
>>754
うちは揉めないけど、やっぱりみんな言語仕様通しの関連が分かってないね
まあ新人はいまどきCなんて嫌だろうし、
ちゃんと理解して使うならC++でもいいよーって許可するんだけどね
ミスらなかった子はひとりもいない、ベテランでもミスる
もちろん仕事だからフォローはするよ

759 :デフォルトの名無しさん:2008/10/08(水) 01:55:58
誰も使わないし誰も使っちゃいけない機能が何であるんだよという素朴な疑問があるだけです
まあ設計者が大した考えもなしに使えるようにしちゃってるだけだけど

760 :デフォルトの名無しさん:2008/10/08(水) 02:09:42
>>741
カンマの左辺で例外が起きたときの問題ってどんなの?

761 :デフォルトの名無しさん:2008/10/08(水) 02:14:53
>>760
ただの関数呼び出しでは評価順序は決まっていないから、
a, bでoperator ,関数が呼び出されるときには、
b, aの順で評価されても構わないということになるはず。

762 :デフォルトの名無しさん:2008/10/08(水) 02:22:18
>>749
なら誰にとってありえるの?
使いこなせないくせに演算子オーバーロード機能使って、しかも&&演算子を…
っていう人間を仮定してみるとあちこち矛盾が生じるのだけれど
使いこなせるのに…もまた然り

763 :デフォルトの名無しさん:2008/10/08(水) 02:59:50
>>762
え?釣りなの?本当に理解できてないの?

764 :デフォルトの名無しさん:2008/10/08(水) 03:12:41
いいかい
問題がある・ないってのは客観なんだ
問題がありうる・ありえないってのは主観なんだ
客観に対して主観で反論したら議論にならないだろう?
これはC++とか関係ない当たり前のことだよ

765 :デフォルトの名無しさん:2008/10/08(水) 03:21:30
>>762
釣りじゃないなら一晩おいて、もう一度よく読み返してみな?
大丈夫、C++の問題点よりずっとずっと簡単な話だよ

766 :デフォルトの名無しさん:2008/10/08(水) 03:56:33
Javaだと回避不能なウンコ仕様が多くて困るけど
(例えばしょうもないことで例外が飛んでくるとかthrowsとか)
C++のウンコは知ってれば回避可能なウンコが多い気がするな

まあ確かにC++にはウンコ満載な気はするけど
知ってしまえばどうということはないので
慣れればあまりフラストレーションが溜まらない、というのが俺の実感

&& || , のオーバーロードの話だって
More Effective C++ に「やるな」と書いてあって、
簡単に納得できるレベルの話だしねえ

767 :デフォルトの名無しさん:2008/10/08(水) 04:07:11
いやいや、中にはそもそもできないようにしろよって主張も上の方にあっただろ。
俺もそう書いた1人だよ。

768 :デフォルトの名無しさん:2008/10/08(水) 04:15:20
>>766
>>764に書かれてる事なんですぐ繰り返すの?ねえ?なんで?ばかなの?しぬの?

769 :デフォルトの名無しさん:2008/10/08(水) 04:35:23
CGIしか作れないようにしたらC++の意味ないよな。
ウケルw

770 :デフォルトの名無しさん:2008/10/08(水) 08:59:01
包丁は販売禁止ですね
わかります

771 :デフォルトの名無しさん:2008/10/08(水) 09:47:29
いや、別に包丁は売ってもいいし、包丁で人が切れてもいいけど、

包丁を使ったと思ったら菜箸だった(ポルナレフAAry

となるのがC++の凄いところ

772 :デフォルトの名無しさん:2008/10/08(水) 09:55:57
>>770
両刃の包丁を買ってきたと思ったら、背側にも刃がある両刃でした

773 :デフォルトの名無しさん:2008/10/08(水) 10:52:24
>>766
> Javaだと回避不能なウンコ仕様が多くて困るけど
> (例えばしょうもないことで例外が飛んでくるとかthrowsとか)

これはウケた

以下のコードはf()は何もthrowしない、と例外仕様で言っているが、
f() throw() { throw 1; }
これをあんたのコンパイラがどう扱うか確認してみればいい

C++では文字列も整数もクラスも
ポインタも参照も、何でもthrowできる
例えばMFCとVC++のCOMサポート、C++標準ライブラリのようなものは
当然のように全く異なる流儀で例外を扱っている
それらを全て捕まえたければ catch (...) を使うしかないが、
これでは何が飛んできたか分からないから、事実上何の役にも立たない
勿論スタックトレースの取得などできるわけもない

C++はJavaの例外を馬鹿にできる立場には一切無いよ

774 :デフォルトの名無しさん:2008/10/08(水) 11:25:14
>>769
operator &&や||をなくしただけで
CGIしか作れなくなるのか

すげえ言語だな

775 :デフォルトの名無しさん:2008/10/08(水) 12:44:13
|| のオーバーロードは昔からあるんだから現実にこの世の中で問題が起きたことを
確認してから批判してくれ。
どうせ || のオーバーロードができなければできないで批判されるだろうから。

776 :デフォルトの名無しさん:2008/10/08(水) 13:50:33
まあほんとは仕事なんててきとーにJavaみたいな言語でやってるのが楽なんだがなあ

777 :デフォルトの名無しさん:2008/10/08(水) 14:28:45
>>773
例外仕様の話は当然知ってるよ
何が起こるかもよーく知ってるし、
色んな本に「使うな」と書いてあることもだ
使わなければ簡単に問題は回避できるだろ?

>それらを全て捕まえたければ catch (...) を使うしかないが、
それぞれどんな例外が飛んでくるかわかるんだから
個別にcatchすればいい
Java で catch (Exception e) がまずいのと同様に
catch (...) は原則として使っちゃだめ
両方ともまったく同じ問題を抱えている

スタックトレースについては仕方ないんじゃない?
そもそもC++の規格は実行スタックの存在すら仮定してないし
余計なデバッグ情報をバイナリに入れないと取得不能だしね

778 :デフォルトの名無しさん:2008/10/08(水) 14:39:08
>>777
ん?Javaの例外がウンコでC++のはそうじゃないんだろ?

一貫性がなく事実上使いものにならない例外仕様
共通のインタフェースの欠如
スタックトレースの欠如

これだけでもJavaの例外より劣ることは明白だが
何をもってC++がウンコでないと言っているんだ?




779 :デフォルトの名無しさん:2008/10/08(水) 14:52:55
> Java で catch (Exception e) がまずいのと同様に
> catch (...) は原則として使っちゃだめ

上と下ではまったく意味が違うんだが。
たしかに「製品クオリティの」コードでは上は避けるべきだが
下とは違い、最低限Exceptionクラスを通して得られる情報だけは
得られる。スタックトレースやエラーメッセージなどがな。

下はゼロだ。完全に。
はっきり言って、こんなものを捕まえるぐらいならクラッシュしてくれたほうが
マシだよ。コアダンプをバックトレースしてみればどこで落ちたかわかるからな。


780 :デフォルトの名無しさん:2008/10/08(水) 14:57:05
>>778
>>766 をよく読んでくれ
C++の例外がウンコじゃないなんて書いてないぞ
むしろC++にはウンコがいっぱいと書いてある

781 :デフォルトの名無しさん:2008/10/08(水) 15:06:36
C++はウンコだらけで臭くて臭くてしょうがないけど、踏まなければ関係ないねって事だよな

そんじゃお前は家の前に毎日ウンコしていく犬が居ても関係無いのかって話だわ

批判してる奴は別にウンコ踏んで怒ってるんじゃなくて
クセエよ片付けろよ、てか初めからウンコしてんじゃねえよって文句言ってるんだよ

782 :デフォルトの名無しさん:2008/10/08(水) 15:11:20
横レスだが

C++がウンコ満載なのは納得した
あんたはウンコ全部よけれるんだぜーて言うけどさ
普通はそんなウンコ満載言語には近づきたくないよw
特にこれからプログラムを学ぶ人間ならな

783 :デフォルトの名無しさん:2008/10/08(水) 15:41:00
横から悪いけど、Javaのthrowsって何がウンコなの?それって一般的な認識?

784 :デフォルトの名無しさん:2008/10/08(水) 15:43:38
>>783
どうせthrowsとかいつも書かされるのが嫌だ、とかいう下らない理由だろう
Javaは例外をインタフェースの一部とみなしているから
はっきり宣言させているのだし、C++よりずっと首尾一貫しているわけだが

C++では関数might_throw()が例外を投げるかどうかを確認するには、
それについているドキュメントを信用するか、それから呼ばれる
コールツリーを全ておっかけるしかない

785 :デフォルトの名無しさん:2008/10/08(水) 15:46:28
>>783
比較的どうでもいいことまで例外投げてきやがってウゼエって個人的感想じゃないの?
必ずキャッチしなければならないから回避不可って

786 :デフォルトの名無しさん:2008/10/08(水) 16:04:41
○○は糞とか、○○はウンコとか言う奴ってさ
大抵の場合、一つの言語しか使えないような低脳野郎だよね


787 :デフォルトの名無しさん:2008/10/08(水) 16:50:20
>>784,785
あぁ、なるほど。スレの流れから考えて、C++に対するウンコは客観的な意味っぽかったから
Javaに対するウンコも同様だろう、と思ったら違ってたのか

要は、流れとは全く関係なく、
Javaは強制される作法が多くて疲れるが、C++はそれがなくていい、って言いたかっただけか。

788 :デフォルトの名無しさん:2008/10/08(水) 17:34:02
ここ数百レスのすれ違いまとめ

批判側
 C++ウンコだらけで臭すぎ、マジ臭い

擁護側
 ウンコを踏む奴はただの馬鹿www
 大体そんな道の端にあるウンコ誰が踏むんだよwww
 だからC++には全く問題がないwww
 ウンコを避けれる俺カコイイwww

批判側
 いや、それじゃ臭い事実は変わらないから・・・

789 :デフォルトの名無しさん:2008/10/08(水) 17:37:30
>>783
http://www.ibm.com/developerworks/jp/java/library/j-jtp05254/
> チェック済み例外に対するいくつかの批判
•チェック済み例外が、実装の詳細を不用意にさらけ出している
•不安定なメソッド・シグニチャー
•読みとれないコード
•例外の飲み込み
•例外ラッピングが多すぎる

790 :デフォルトの名無しさん:2008/10/08(水) 18:08:50
大暴落のおかげで腐りかけてたN225のプットワラントが
20倍近くになってうまうまなんだが。

791 :デフォルトの名無しさん:2008/10/08(水) 22:32:23
信者:C++の何が問題なのか言ってみろ!
アンチ:&&や||をオーバーロード出来る事に問題がある
信者:そんなの普通は使わない、だから問題無い!
アンチ:新人が絶対それ使わないってあんたが保障してくれるの?

信者:北朝鮮の何が問題なのか言ってみろ!
アンチ:核ミサイルを持ってることに問題がある
信者:そんなの普通は使わない、だから問題無い!
アンチ:正日が絶対それ使わないってあんたが保障してくれるの?


792 :デフォルトの名無しさん:2008/10/08(水) 22:39:26
安全かどうかはこの際どうでもいいんだけどね
不愉快で醜いウンコには俺の前から消えて欲しいだけで

793 :デフォルトの名無しさん:2008/10/08(水) 22:45:03
C++の例外がヤバイってのは分かるとしても、|| && の批判はバカじゃねえのと思わずにはいられない。

794 :デフォルトの名無しさん:2008/10/08(水) 22:45:46
世界恐慌〜WW1
 アメリカ->ニューディール政策
 ロシア->共産化
 その他→植民地補充合戦

もうお分かりですね?

795 :デフォルトの名無しさん:2008/10/08(水) 22:48:06
核なら怖いが、破裂しないバクチクに安全保障などしなくて良い

796 :デフォルトの名無しさん:2008/10/08(水) 22:53:02
C++ のヤヴァイ所は全部ストラウストラップのチェックを通って世に出されたんだよね?

797 :デフォルトの名無しさん:2008/10/08(水) 22:54:16
D&Eを見る限り、興味ない所はろくにチェックしてないようだがな
741のように

798 :デフォルトの名無しさん:2008/10/08(水) 23:09:53
そもそも罠で作ったってどこかで言ってたよ

799 :デフォルトの名無しさん:2008/10/08(水) 23:17:47
本当にわかってないのかな?
&&のオーバーロードなんてのはあくまでも例であって
問題点を認められない狭量さを揶揄されてるんだよ

「自分は平気だからそれは問題ではない!」
こんな主張がアリなら、どんな糞言語のどんな糞仕様でもなんでもアリになってしまう

800 :デフォルトの名無しさん:2008/10/08(水) 23:19:09
坊主憎けりゃ袈裟まで憎いとw

801 :デフォルトの名無しさん:2008/10/08(水) 23:20:42
つーかそこは設計者の資質自体が疑われるところだろ
実害の有無以前の問題として、あまりにアホすぎてな
情報系の学生の演習問題レベルのミスだ
禿はラリっていたとしか思えない

802 :デフォルトの名無しさん:2008/10/08(水) 23:35:14
スティールやヴィルトみたいなプロの言語設計者が作った言語じゃないからね。
悪態付いても祈っても、最早どうしようもないし、取り返しも付かない。

803 :デフォルトの名無しさん:2008/10/08(水) 23:37:35
perlなんてミスの権化だな、使える言語だが。完璧主義など糞くらった方が良い
C++否定派の俺からしても、こういう愚かな批難は同意しかねますね。

804 :デフォルトの名無しさん:2008/10/08(水) 23:39:24
いやPerlなんて普通に使わないが。
もっとマシな「Perlのようなもの」があふれているからな。

805 :デフォルトの名無しさん:2008/10/08(水) 23:42:01
>>791
ミサイルは取り返しがつかないが、ソフトウェアなら取り返しがつく。
#頼むから新人は取り返しのつくようなところに使ってくれ。

806 :デフォルトの名無しさん:2008/10/08(水) 23:43:15
Perl と C++ は似てるよね。汚いから嫌われている。

807 :デフォルトの名無しさん:2008/10/08(水) 23:45:40
また話のすり替えかな

808 :デフォルトの名無しさん:2008/10/08(水) 23:47:16
今、話のすり替えの話にすり替えた人を見た

809 :デフォルトの名無しさん:2008/10/08(水) 23:47:53
>>805
>>799

810 :デフォルトの名無しさん:2008/10/08(水) 23:48:30
C#がネイティブ吐けたら終了

811 :デフォルトの名無しさん:2008/10/08(水) 23:49:22
>>810
それ、あんまり意味無いと思うよ
今だってngenでネイティブコンパイルできるが
C++の代用にはならない

812 :デフォルトの名無しさん:2008/10/08(水) 23:56:58
MFCってやつに取って代わることは出来るかもな

813 :デフォルトの名無しさん:2008/10/09(木) 00:08:38
>>799
なら、どういう書けば問題を認めるってことになる?

実際問題、&&は反論しようのないことだ。
どうせ禿のことだ、今更&&禁止とかやるわけがない。
C++を使う側としては、使わない、つまり運用で回避するしかないという現状を述べただけ。
たしかに顔真っ赤にしているようにしか見えないのがほとんどだったが。

814 :デフォルトの名無しさん:2008/10/09(木) 00:18:18
反論しようの無いことだと思ってるんなら
別に黙ってればいいだけじゃね?

815 :デフォルトの名無しさん:2008/10/09(木) 00:34:11
だってさ、誰も使っていない(と思っている)ことでそんなに言われるとさ、つい。

逆に、例外では沈黙に傾いていたと思うよ。
使っていて実感しているから、こっちこそ何も言えない。

816 :デフォルトの名無しさん:2008/10/09(木) 00:51:34
仕様はともかく、危険なのはコンパイラでデフォルト動作で禁止すればいいだけの気はするがw

817 :デフォルトの名無しさん:2008/10/09(木) 01:31:50
operator&&くらいなら簡単に警告出せるだろうけど、危ない機能はまだまだあるからな
継承ハイジャックとか

818 :デフォルトの名無しさん:2008/10/09(木) 01:38:19
>>813
言語に問題があることを認めた上で、「黙って」運用で回避する
たったそれだけのことじゃないかな

例えば>>749はアンチだが最初からこう言っている
>問題はあるけど回避可能だからC++を使おうって判断はそれぞれの職場でやればいい

819 :デフォルトの名無しさん:2008/10/09(木) 01:42:14
それなりにC++のノウハウが高い会社にいくとC++の例外は上手に使ってるよ。
ゲーム関係とか。罠を避けつつ、うまく例外クラスライブラリとかスタックトレースとか
組み上げてる。
そういうノウハウをその辺の入門書読んだだけじゃ上手に学べないという罠が
あるけど。

820 :デフォルトの名無しさん:2008/10/09(木) 01:47:24
いや何と言っても #define private public が一番危ないw

821 :デフォルトの名無しさん:2008/10/09(木) 01:49:17
RTTI はともかく、ゲームや組み込みでは、まだ当面、例外はいらんだろう。

822 :デフォルトの名無しさん:2008/10/09(木) 01:59:14
ゲームといってもPCとコンシューマじゃまるで状況が違うよ
環境によって例外はそもそも使用禁止だったりするし
合理的な会社は当然マルチプラットフォーム前提で作るから例外は使わないね

823 :デフォルトの名無しさん:2008/10/09(木) 02:00:12
Album Title : 恋、はじめました!(OP)/LoveLoveLoveのせいなのよ!(ED)

824 :デフォルトの名無しさん:2008/10/09(木) 02:44:06
PS3とXboxとPCのクロスのUnrealエンジンは例外使ってるけどね

825 :デフォルトの名無しさん:2008/10/09(木) 03:38:21
同じゲームでも、もともとPC、というかWindowsメインだと例外も使ってる(こともある)
でもいまコンシューマ業界はDSとWiiが主流だからねえ……。
コンシューマ業界全体からみたら例外を使うのはレアケースになっちゃう

826 :デフォルトの名無しさん:2008/10/09(木) 09:01:48
要するに
D言語がVisualStudioで使えれば全ては解決する
VSで使えるのがC++しか無いから使ってるだけだろ。

827 :デフォルトの名無しさん:2008/10/09(木) 09:57:52
評価順序や引数展開でごちゃごちゃするのがイヤならAlgol系言語は全部ダメだな。
Lisp最強

828 :デフォルトの名無しさん:2008/10/09(木) 10:14:04
Lisp好きもbindやlambdaがC++0xで入るからちっとは楽しめるようになるぞ。
実用的アプリやフリーソフトを泥臭いWin32と美しい関数型プログラミングを組み
合わせて設計できるようになるのは楽しそうだ。

829 :デフォルトの名無しさん:2008/10/09(木) 10:32:16
>>826
Dて。どこをどう「要するに」なんだよw

830 :デフォルトの名無しさん:2008/10/09(木) 11:08:02
>>828
そんなのカオスになるだけだろ。
右結合、左結合、優先順位、左の評価次第で右を評価するかどうか決まる、などの演算子の一目見ただけではわからないルールがさらにオーバーロードされると振る舞いが変わる、などが混乱の元だというのだから、
構文解釈が一目でわからないAlgol系は全部ダメだと言ってるんだよ

831 :デフォルトの名無しさん:2008/10/09(木) 11:15:21
>>828
あんな汚い物でも lambda があれば良いというのは非常に C++ 的な発想ですね。
その点 Java のクロージャは分かってるなあと思うよ。シンプルで奇麗に書ける。
ゴスリングは良いバランス感覚を持ってるね。

832 :デフォルトの名無しさん:2008/10/09(木) 11:46:09
Lambdaが入ったらC++を本格的に使おうと思う

833 :デフォルトの名無しさん:2008/10/09(木) 11:52:22
>>832
lambdaなんて他の言語にフツーに搭載されてる仕様だろ?

今現在既に仕方なくC++を使わざるを得ない・使っている人が、
こんなものでもないよりはマシ、と思うかどうか、という次元の話じゃないの

lambda入ったから使ってみっかってのは正直意味不明な動機だ

834 :デフォルトの名無しさん:2008/10/09(木) 12:12:37
いやフリーソフトとかを作れる言語で関数型プログラミングができるのは
魅力的だなと思ったので。。

835 :デフォルトの名無しさん:2008/10/09(木) 12:16:31
関数型プログラミングは関数型言語でやるのが一番快適。

836 :デフォルトの名無しさん:2008/10/09(木) 12:21:12
いや今ドトネトやってるけど実行環境とかうるさいからやっぱC++にしようと思ってる。
Haskellを勉強して関数型はおもしろいと思ったけど実アプリ開発にはやっぱ難しいと思う。
概念をC++のLambdaで生かせればいいかなと思ってる。

837 :デフォルトの名無しさん:2008/10/09(木) 12:46:34
Cは低級。
故に他の言語と混ぜることも困難ではない。
しかし、C++で拡張された部分はどーしようもない。

838 :デフォルトの名無しさん:2008/10/09(木) 12:55:55
お前がどう思おうと世の中ではふつーに使われてるからwww

839 :デフォルトの名無しさん:2008/10/09(木) 13:42:49
>>819
C++の例外はやめた方がいい、本物の罠だから
例外はガベージコレクタを持たせないと問題が連発してしまう。
特に operater new との組み合わせは、ひどい有様になるので・・・
&& || とは訳が違う、boostあたりでも自在に使えるC++をきわめている人間でも苦しい問題が数多くある。

840 :デフォルトの名無しさん:2008/10/09(木) 13:43:37
ゲームの場合 operator new をオーバーロードする事は多いと思う、だからより用心すべき。

841 :デフォルトの名無しさん:2008/10/09(木) 15:16:08
>839
kwsk

842 :デフォルトの名無しさん:2008/10/09(木) 18:10:37
そんなどうでもいいような重箱の隅つつく話よりも、C++の++のほうが問題
大きいんじゃないか?
なんて呼べばいいのかわからんだろ。

843 :デフォルトの名無しさん:2008/10/09(木) 18:14:56
ぷ〜らぷら

844 :デフォルトの名無しさん:2008/10/09(木) 19:51:54
ようするに

operator && || が本物と同じ動きにすればよかっただけだろ?

845 :デフォルトの名無しさん:2008/10/09(木) 20:40:48
C++はC言語に比べてエラーを無視するプログラマが増えた、と思う

846 :デフォルトの名無しさん:2008/10/09(木) 21:03:36
意味わかんねぇ
エラーってコンパイルエラーか?
どうやって無視するんだそれ

847 :デフォルトの名無しさん:2008/10/09(木) 21:12:35
戻り値無視だろjk

848 :デフォルトの名無しさん:2008/10/09(木) 21:13:05
exceptionとerrorの違いがわからないプログラマが増えた、と思う

849 :デフォルトの名無しさん:2008/10/09(木) 21:30:12
>>844
できるわけねーだろ、タコ

850 :デフォルトの名無しさん:2008/10/09(木) 21:51:46
律儀にstd::bad_allocなんて拾ってられませんよねー

851 :デフォルトの名無しさん:2008/10/09(木) 22:17:28
>>849

本物の && ||がしてる方法をそのまま使えばいいんだが
できるわけねーなら本物もできるわけねー

852 :デフォルトの名無しさん:2008/10/09(木) 22:21:09
>>850
拾えばいいじゃない。

スマートポインタを使わないとメモリリークするからガベコレないと例外使えないと逝ってるんじゃねーの。
俺はそれよりも、try中でスコープ切られてるから、オブジェクトを作ってから死ぬまでtry中に書かねばいかんのがうざいね。

853 :デフォルトの名無しさん:2008/10/09(木) 22:22:42
>>851
できるわけねーだろ。
オーバーロードするのは&& ||「関数」なんだからな。

854 :デフォルトの名無しさん:2008/10/09(木) 22:23:35
メモリが足りないなんていう非常事態で
例外みたいな砲丸を悠長に投げられるほどコンピュータが健康だなんて状況はちょっと考えられない
拾おうが拾うまいがクラッシュするんだから別によくね

855 :デフォルトの名無しさん:2008/10/09(木) 22:23:52
main()
{
try
{
//uiui
}
catch(...){}
}

856 :デフォルトの名無しさん:2008/10/09(木) 22:24:44
>>853
関数以外で書かせりゃいいだろ

857 :デフォルトの名無しさん:2008/10/09(木) 22:24:48
C++がlazyとか持ってれば良かったんだけどねー
いらん機能はいっぱいあるくせにこういう肝心な機能がないのがC++

858 :デフォルトの名無しさん:2008/10/09(木) 22:25:37
スマポかガベコレないと、例外は使う気起きないわなぁ

859 :デフォルトの名無しさん:2008/10/09(木) 22:26:03
>>856
良いシンタクスの考えがあるなら是非標準化委員会に提案して下さい

860 :デフォルトの名無しさん:2008/10/09(木) 22:26:55
>>851
> 本物の && ||がしてる方法をそのまま
これはない
C++には実行時に式を評価する手段が無いのだから

やるなら、右オペランドを、bool値を返す関数にくるんでoperator &&に渡す
operator &&の中で右オペランドを評価したい場合はその関数を呼ぶ
そういう形になるな

が、そこまでする必要は無いだろ
.演算子のように、単に&&や||もユーザ定義できないようにすればよかっただけ

861 :デフォルトの名無しさん:2008/10/09(木) 22:33:47
bool operator &&(const Hoge &lhs, const Hoge &(*rhs)())
{
 return lhs & rhs();
}

解決しました^^

862 :デフォルトの名無しさん:2008/10/09(木) 22:35:31
<<で文字書いたりするのはどう思う?

863 :デフォルトの名無しさん:2008/10/09(木) 22:35:49
>>861
そうそう
つか、「bool値を返す関数」じゃなかったな、スマソ

デフォで遅延評価の機能を持たない言語での一般的なやり口だな
lambda式でくるんでやるのは

864 :デフォルトの名無しさん:2008/10/09(木) 22:36:51
vectorなどSTLコンテナにポインタ食わせても、死ぬとき自動で解放してくれないからな。
そのくせauto_ptrはコンテナに食わせられないし。
かといって、コンテナから派生できないから自分でデストラクタ書くわけにもいかんし、
まあ、いろんな機能を入れた割には標準の範囲内では上手く動かんのよね。

865 :デフォルトの名無しさん:2008/10/09(木) 22:38:20
>>832
当たり前だけど Lambda が入っただけでは関数型言語にはならないでしょ。
関数型言語が便利なのは、言語仕様や組み込みの関数やライブラリが
宣言的にプログラムを書く事を前提として作られているからであって、
Lambda があれば良いという物ではない。関数が引き数に関数を受けて
関数を戻り値として返す事が自然に出来て、副作用は奇麗に分離出来て、
末尾再帰をジャンプに置き換えてくれるから再帰的な定義も自然に書けて、
みたいなね。

関数と変数をまとめてクラスという名前にしただけではオブジェクト指向
とは言えないのと一緒。多態とか継承とかが無いとね。

866 :デフォルトの名無しさん:2008/10/09(木) 22:45:29
STLがいろいろと不備でそれカバーするのがboostとか言う変態ライブラリだろ
最悪じゃね?

867 :デフォルトの名無しさん:2008/10/09(木) 23:11:29
boostみたいなゲロの塊を
「最先端のライブラリや!」とか勘違いされると非常に困る

868 :デフォルトの名無しさん:2008/10/09(木) 23:48:31
つか || && ごとき現実には対応すらするかよっての
普通に作って問題発生せんわ

869 :デフォルトの名無しさん:2008/10/09(木) 23:52:04
>>865
中途半端に<algorithm>なんてものがあるからたちが悪い。

870 :デフォルトの名無しさん:2008/10/09(木) 23:55:30
>>810
つcrossnet

871 :デフォルトの名無しさん:2008/10/09(木) 23:58:32
>>867
バッドノウハウを作り続けているという意味で最先端ではないか。

872 :デフォルトの名無しさん:2008/10/09(木) 23:59:29
>>799
どうでもいい所からつつくから標準化委員会に相手にされない
重要度と優先度と危険性がごちゃまぜになってるマなんか笑われても仕方ない

873 :デフォルトの名無しさん:2008/10/10(金) 00:02:06
> 重要度と優先度と危険性がごちゃまぜになってるマなんか笑われても仕方ない

些細なバグだろうとバグはバグっしょ
そんなバグどうでもいいよ、とかお前さん
バグレポ出してきた客に言うの?


874 :デフォルトの名無しさん:2008/10/10(金) 00:05:41
>872
なんでいまさら終わった話題に、しかも斜め上のレスしてるの?

875 :デフォルトの名無しさん:2008/10/10(金) 00:16:23
それは872自身が重要度と優先度と危険性がごちゃまぜになってるマだからだよ

876 :デフォルトの名無しさん:2008/10/10(金) 00:17:02
&& || の問題など
e = a*b+c*d;
についてオプティマイズでa*bが先に計算されるかc*dが先に計算されるか分からなくて不明だから、問題だといっているような物だ。
ただのアホ

877 :デフォルトの名無しさん:2008/10/10(金) 00:19:33
>>874
ということにしたい気持ちはよくわかる

878 :デフォルトの名無しさん:2008/10/10(金) 00:20:49
オプティマイズの話よりセマンティクスの話の方が、よりクリティカルだと思うけど。
優先度ってそういう事だろ。

879 :デフォルトの名無しさん:2008/10/10(金) 00:22:03
オイオイ、また同じ話を繰り返すのか?
>>799と前後の流れを100回読み直せ
マジで理解できないなら相当頭悪いよ

880 :デフォルトの名無しさん:2008/10/10(金) 00:22:17
で、例外の話にはつっこまないのな。

881 :デフォルトの名無しさん:2008/10/10(金) 00:23:53
i++ && j++

&&の振る舞いが異なるのが最適化の誤差程度ですか、そうですか。

882 :デフォルトの名無しさん:2008/10/10(金) 00:26:51
open("hoge") or die;
とかPerlでよく書くけど、orの意味変わったらどうなると思ってるんだよ

883 :デフォルトの名無しさん:2008/10/10(金) 00:27:04
>>873
それ前提が間違ってるから
意図的にバグ埋め込むテロリストみたいな奴にコード書かせる奴のほうが悪い
そんな危険な奴相手なら書かせないかけコードレビューをきっちりするか
コード検証ツールで定期的に確認するか
或いはさっさとクビにするか。

意図せずに埋め込むなんざありえんよ

884 :デフォルトの名無しさん:2008/10/10(金) 00:27:31
1ステートメントに++が2回出てきてる時点で論外ですわ
++、--、=ファミリーは1行に1個まで、守らないと鼻から悪魔よー

885 :デフォルトの名無しさん:2008/10/10(金) 00:28:53
>>883
脆弱性がバグではないと言い張れたら
MSもこんなにセキュリティパッチを連発する必要無いんだけどね

886 :デフォルトの名無しさん:2008/10/10(金) 00:29:00
>>882
operatororとかないから
てかC++の話だから、グロスクリプト言語はお引き取り下さい

887 :デフォルトの名無しさん:2008/10/10(金) 00:29:04
振る舞いが違っていても問題ないようにコード書くよう教育されているだろ、普通。
カッコつけろ、いったん変数に入れろ、こんなの基本。

888 :デフォルトの名無しさん:2008/10/10(金) 00:29:49
>>886
C++でもPerlと全く同じことなのだが
理解できていないようですね

889 :デフォルトの名無しさん:2008/10/10(金) 00:30:36
アンチは危険性の指摘云々じゃなく自分の好きな話がしたいだけだろ
C++で開発したこと無いんじゃないかってくらい、現実を見てない指摘

もっと危なくて新人ならよくやるポカが沢山あるのに。

890 :デフォルトの名無しさん:2008/10/10(金) 00:30:53
>>884
副作用のある物を演算子ののオペランドにしたらどうなるという広い課題に対して、
挙げた一例に対する煽りしかできない時点でバカを自白しているようなもんだ。

891 :デフォルトの名無しさん:2008/10/10(金) 00:31:24
まさか
check(x) && exit(1);
とか書いてる奴がいるの?

そんな奴はプログラマやめて下さい

892 :デフォルトの名無しさん:2008/10/10(金) 00:32:01
C++は本当に大問題ありだが、こんな批判がでるとC++が無問題のように見えてしまうから大問題だ。

893 :デフォルトの名無しさん:2008/10/10(金) 00:32:08
>>884
881のことならその点は問題ないだろ。
iとjが実体は同じ、例えばint& i = j;とでもしているのでない限り。

894 :デフォルトの名無しさん:2008/10/10(金) 00:32:16
>>889
で、例外機能についてはどう思う?

895 :デフォルトの名無しさん:2008/10/10(金) 00:33:14
>>891
仕事ではやらないので勘弁してください。

896 :デフォルトの名無しさん:2008/10/10(金) 00:33:38
>>891
while ((c = getchar()) != EOF && c != '\n')....
とか普通にかけるでしょ

何のために「わざわざ」&&や||が副作用完了点とされ、
評価順序が厳密に仕様で定義されてると思ってるのかしら

897 :デフォルトの名無しさん:2008/10/10(金) 00:35:06
>>896
ヤメロぼけかす死ね
優先順位で副作用作るな

898 :デフォルトの名無しさん:2008/10/10(金) 00:36:08
>>897
優先順位?

馬鹿確定
仕様理解してないだろ

899 :デフォルトの名無しさん:2008/10/10(金) 00:36:21
>>887
(軽い判定) && (重い判定)
でもいったん代入するんですか。
(副作用のない判定) && (副作用の出る関数の辺値)
もいったん代入するんですね。

900 :デフォルトの名無しさん:2008/10/10(金) 00:37:57
while (true)
{
 c = getchar();
if( c != EOF && c != '\n')....
}

こうかけ、非常識なコード書くな

901 :デフォルトの名無しさん:2008/10/10(金) 00:38:52
perlでは短絡を使うが、それ以外では短絡を使わないな。

902 :デフォルトの名無しさん:2008/10/10(金) 00:39:13
なるほど、K&Rや禿は非常識なんだな

903 :デフォルトの名無しさん:2008/10/10(金) 00:39:31
>>896
そんなふざけたコード書いて悦に入ってる輩のせいで
真似してカオス文書くアホが後を絶たないんだ
やめてくれよ

while(1)
{
 c = getchar();
 if(c == EOF || c== '\n')
 {
  break;
 }
 ...
}

904 :デフォルトの名無しさん:2008/10/10(金) 00:40:29
テキストの1バイトも無駄に出来なかったK&Rの時代のバッドノウハウを
ギガバイト時代に持ち込まないで下さい
本当にやめて下さい

905 :デフォルトの名無しさん:2008/10/10(金) 00:41:53
>>904
お前がバットノウハウだ
お前が死ね、今でもこの手の基本は流石に変わらんわボケ


906 :デフォルトの名無しさん:2008/10/10(金) 00:42:22
話は逸れるが、個人的にはこういう風に書けるのが好き。
while (get(&c)) //結果はcに入る。EOFなら偽を返す。

907 :デフォルトの名無しさん:2008/10/10(金) 00:43:28
>>906
そこまでならば許容だが・・・

908 :デフォルトの名無しさん:2008/10/10(金) 00:44:28
>>899
そんなに重いんだったらこうだな
if(軽い判定){
 if(重い判定){
  ...
 }
}
もしくはこう
if(軽い判定){
 return;
}
if(重い判定){
 ...
}

&&よりよっぽど明確

909 :デフォルトの名無しさん:2008/10/10(金) 00:45:51
まぁ異常なコードを書けば些細な問題が表面化するのも仕方がないというか・・・ヤメロあほたれ

910 :デフォルトの名無しさん:2008/10/10(金) 00:46:45
C++信者大好きなboostで&&が使われてるかどうか見てみたら?

&&は非常識、なんでしょ

911 :デフォルトの名無しさん:2008/10/10(金) 00:46:55
>>905
うるせえよ化石
896の利点は何だ?
読みやすい?お前だけだ
速い?コンパイラの最適化なめんな

いい加減に馬鹿げた短縮構文なんか捨てろよ
何で一行にグチャグチャ押し込めなきゃならないんだよ

912 :デフォルトの名無しさん:2008/10/10(金) 00:50:05
>>910
分かっていて使うやつらはちゃんと把握してコードされてるだろ、使う側が適当でも問題でないようになってるから。

913 :デフォルトの名無しさん:2008/10/10(金) 00:50:15
getcharとwhileは100歩譲ってまだ分からなくもないとしよう。
だが、ifでやる奴は本当消えてほしい、無論C++に限らない。
hoge_type x;
if ((x = get_hoge()) != xxx)


914 :デフォルトの名無しさん:2008/10/10(金) 00:51:21
逆にコンパイラが遅いとか言ってるのは、おまいのマシンが時代遅れなだけじゃないのかとw

915 :デフォルトの名無しさん:2008/10/10(金) 00:52:01
C++ のコンパイラは遅いよ。言語仕様がそうさせてるから仕方が無い。

916 :デフォルトの名無しさん:2008/10/10(金) 00:52:35
while(*dst++ = *src++);みたいなのを
「大事なテクニックだからしっかり覚えるべき」みたいに書いてるK&Rは
禁書に指定すべき

こんなものがバイブルになってるからCとその子孫はいつまでもダメなんだ

917 :デフォルトの名無しさん:2008/10/10(金) 00:52:40
boostといえば、スマートポインタの代入等で発生する回避しがたい例外の問題についてswapを使って例外の問題を封じ込める所とか衝撃だったな
普通の人は気付かない問題もこれを使えば表面化しない。

918 :デフォルトの名無しさん:2008/10/10(金) 00:53:24
ソースなんて当然人も読み書きするものなのに
計算機ですらあんなにコンパイルに時間がかかる仕様でいいのか、
という当然の疑問は持ってしかるべきだと思うんだけどね

919 :デフォルトの名無しさん:2008/10/10(金) 00:55:49
C++ 以外を無視すれば、コンパイルが遅い事なんて気にならない。
C++ が使えないなら幾ら早くなっても意味無いよ。

920 :デフォルトの名無しさん:2008/10/10(金) 00:58:21
ダメだこいつ早く何とかしないと

921 :デフォルトの名無しさん:2008/10/10(金) 00:59:10
>>919が哀れに思える。

>>917
代入演算子でswap使う話はExceptional C++にも解説されている。

922 :デフォルトの名無しさん:2008/10/10(金) 01:00:23
で、この低レベルなグダグダ議論はいつになったら終わるんだ?

脚からバグについてつつかれても
そんなのお前しか使わないよバーカバーカとか言って済むとでも
思っているのだろうか

>>885に関しても完全にスルーだね
C++信者はどうもパラレルワードに生きているらしい

923 :デフォルトの名無しさん:2008/10/10(金) 01:01:06
まともにレスすると負けるから荒らしに切り替えたんでしょ
とりあえずsageろよ

924 :デフォルトの名無しさん:2008/10/10(金) 01:01:17
>>921
逆にこれを見たとき、C++で例外は使っちゃだめなんだと確信したけどね。
ここまでやらないとバグが潜伏するんだと・・・

925 :デフォルトの名無しさん:2008/10/10(金) 01:04:12
パッケージソフトでも C++ で書かれているのはそこそこあると思うけど、
例外を使ってるソフトって無いの?

926 :デフォルトの名無しさん:2008/10/10(金) 01:10:29
あるだろうけど、だから何?

927 :デフォルトの名無しさん:2008/10/10(金) 01:10:50
質の高いソフトは注意深くしっかり使ってるか、使わないことを徹底してるかだろうけど
世の中の大半は中途半端に使ってて、そしてご存じの通り質が低い
使うにしろ排除するにしろ、しっかりやるとなるとコスト半端ないから

928 :デフォルトの名無しさん:2008/10/10(金) 01:18:52
俺はthrowしないとかは勝手なんだが、newもキャストもthrowしてくんだからしっかり
対応はしとけよ。
俺は例外使わないとか馬鹿ルール勝手に設けてリークしまくりのコード書くバカは
マジで困るよ。

929 :デフォルトの名無しさん:2008/10/10(金) 01:22:06
ガベージコレクタをサポートしない言語で例外を取り扱うのは非現実的だよ、どんなに注意深く作っても漏れがでる。
なぜならキャッチして自分の把握している範囲だけをdeleteすればメモリーリークを回避できるというものではないから。

930 :デフォルトの名無しさん:2008/10/10(金) 01:24:34
>>922
上のほうにそういう話あったじゃない。
スルーは図星の証。
もっとそういう息の根を止められるような話が欲しい。

>>929
それだけだと、スマートポインタがどうのとかって言われるぞ。



931 :デフォルトの名無しさん:2008/10/10(金) 01:25:39
>>930
例外導入するなら例外安全なスマートポインタの採用は不可避かと

932 :デフォルトの名無しさん:2008/10/10(金) 01:25:47
GCをでっかいスマートポインタの塊だと思ってる人たちに何を言っても無駄

933 :デフォルトの名無しさん:2008/10/10(金) 01:26:24
>>928
うちのC++大好きな部下(not新人)とかまさにそんな感じ
正味の話、教育コストは高すぎだな

934 :デフォルトの名無しさん:2008/10/10(金) 01:27:44
キャストが例外投げるのは知らない奴多いよな

935 :デフォルトの名無しさん:2008/10/10(金) 01:28:49
おれは理解すれば理解するほど、教育でなんとかなるような問題ではないと思うよ > 例外
分かっていても、なんだかの自動サポート無しでは無理だ

936 :デフォルトの名無しさん:2008/10/10(金) 01:34:43
デストラクタのない言語のほうが例外は面倒じゃないか?

937 :デフォルトの名無しさん:2008/10/10(金) 01:36:36
>>936
メモリ以外のリソースの扱いは比較的局所化しやすいけど
メモリはまず無理だよね

938 :デフォルトの名無しさん:2008/10/10(金) 01:38:53
だから両方が必要なんだよな

片方ずつしかないC++とJavaは両方ともダメだ

939 :デフォルトの名無しさん:2008/10/10(金) 01:39:22
少なくともnew/castなど言語レベルで出してくるもの、STL/boostや利用ライブラリがthrow
してくる例外にはリソース管理(shared_ptr/auto_lockなど)もしくは、catchしてリソース解放など
適切な処理をすることは絶対の義務。これができてないコードは完全なバグ。
その上で、自分の関数を戻り値返しにするかthrowで例外モデルにするかはポリシーの問題。

940 :デフォルトの名無しさん:2008/10/10(金) 01:42:48
>>939
みんながそうやってくれないのが最大な問題なんだよorz

941 :デフォルトの名無しさん:2008/10/10(金) 01:43:56
そういう話になるとRAIIがよく登場するが
RAIIもうちじゃ使い物にならん、ほぼ却下してる
そんなわけでアホみたいにtry~catch、逆に開発効率悪い罠

942 :デフォルトの名無しさん:2008/10/10(金) 01:44:46
new(std::nothrow)とか全員に律儀に書かせろという方が無茶な話なんだよな
現実的に考えて

943 :デフォルトの名無しさん:2008/10/10(金) 01:48:17
>>942
それはそれでNULLチェックしないっていうオチなんだよな
聖典D&Eにも、ぼんくらな平均的プログラマは絶対NULLチェックやらないから
そこんとこ対処しないとって話がある。まだnewハンドラの時代のことだけど。

944 :デフォルトの名無しさん:2008/10/10(金) 01:48:45
メモリ管理はスレッド化すれば無問題。

945 :デフォルトの名無しさん:2008/10/10(金) 01:50:53
RAIIはロックとかソケットとかファイルハンドルとかの管理にはすごく便利だけど
メモリの管理まで任せらせるようなものじゃない

メモリとそれ以外の共有リソースって本質的に違うよな
C++もJavaも(方向は正反対だけど)一緒くたに扱おうとしちゃってるあたりは同じ穴のムジナ

946 :デフォルトの名無しさん:2008/10/10(金) 01:51:23
mallocでちゃんとnullチェックする子もなぜかnewは何もしない不思議だがよくある

947 :デフォルトの名無しさん:2008/10/10(金) 01:54:43
その子は正しい

948 :デフォルトの名無しさん:2008/10/10(金) 01:56:34
>>947
いやいや上層部でのcatchすらしないってことでしょ、おそらく。

949 :デフォルトの名無しさん:2008/10/10(金) 01:58:06
例外版newにせっせとNULLチェック付けてやり遂げたような顔してる奴よりはまし

950 :デフォルトの名無しさん:2008/10/10(金) 01:59:23
次スレ代わりに似たようなテーマのスレ

C++は難しすぎ 難易度:4
http://pc11.2ch.net/test/read.cgi/tech/1221557484/l50

951 :デフォルトの名無しさん:2008/10/10(金) 02:00:31
mainの最上位で
catch(bad_alloc){ メモリが足りません。exit }
ってのも男らしくていいと思うぞ。

952 :デフォルトの名無しさん:2008/10/10(金) 02:05:53
まぁ、このスレは板にしては何だかんだ言っても盛り上がったなw

953 :デフォルトの名無しさん:2008/10/10(金) 02:08:19
>>951
個人的ツールならいつもそれ

954 :デフォルトの名無しさん:2008/10/10(金) 02:21:52
やっぱC++が主要な言語である割には、難解すぎたり問題点が多いから、
議論が絶えないんだろうな。
939のレベルで皆が理解してたとしてもまだRAIIとかその例外中立をどう保つのかの
ポリシー決めとか、実際にすべてのコードをそういう状態に保ち続けられるのかとかの
困難さも残るしな。

そういう困難さを解決したはずのJavaは、その代償のガベージコレクションの動作速度で
別の問題を抱えてC++を駆逐したとは言い難いし、それをさらに改良してヒープとスタックを
選んで作れるようにしたC#もまだ主流とは言い難いし、いったいなにが正解なんだろうな。

955 :デフォルトの名無しさん:2008/10/10(金) 02:23:19
その辺でDには期待してた
期待してたんだ

悲しいよ

956 :デフォルトの名無しさん:2008/10/10(金) 02:24:23
>>885
日本語でおk
全く噛み合ってないわお前のレス

957 :デフォルトの名無しさん:2008/10/10(金) 02:26:03
>>954-955
それと、C++0xはさらに肥大化の方向ということも追加。
Committee Draftまだ見ていないけど。

958 :デフォルトの名無しさん:2008/10/10(金) 02:37:07
GCマンセーもRAIIマンセーも間違いで、どっちも必要なんだよな
細かい所はGCに任せて安全性を確保するのも大事
肝心な所はプログラマが寿命をしっかり管理できるようにするのも大事
DとかC#とかはどっちも出来るようになってるし

だからC++0xがGC対応しないことには失望した

959 :デフォルトの名無しさん:2008/10/10(金) 02:42:11
実にその通りだが、どっちか一つ選べって言われたらGCなんだよな
局所性のあるリソース管理はまだしもフォローしやすいが
メモリだけはどうしようもない

960 :デフォルトの名無しさん:2008/10/10(金) 02:46:12
最初に習うHello worldが悪い。これをテンプレにしてあげないと。
#include <cstdlib>
#include <iostream>
int main(int argc, const char *argv[]) try
{
std::cerr << "hello world!" << std::endl;
return EXIT_SUCCESS;
} catch (...) {
std::cerr << "unexpected world!" << std::endl;
return EXIT_FAILURE;
}

961 :デフォルトの名無しさん:2008/10/10(金) 02:47:19
組み込みのARMやPPC, DSP好きのオレ様はGCは全く許容できない

962 :デフォルトの名無しさん:2008/10/10(金) 02:47:32
hello worldをcerrに送るのはおかしいだろwwww

963 :デフォルトの名無しさん:2008/10/10(金) 02:55:07
>>958
1xとか2xに入るんじゃないかw

964 :デフォルトの名無しさん:2008/10/10(金) 02:57:44
C++/CLIのハンドル取り込んじゃえばいいのに…

965 :デフォルトの名無しさん:2008/10/10(金) 02:58:54
C++が対象にしようとしているドメインが広すぎて結局どっちつかずなんだよ

GCなしなら最初から例外もなしで、Cよりは便利なADTやクラスが使える、ぐらいの
言語のほうがナンボかすっきりする
デフォルト引数なんてのもいらんだろ

もっと高級なものを志向するんなら、それなりの道具立てをそろえなきゃダメだ

966 :デフォルトの名無しさん:2008/10/10(金) 02:59:36
>>945
すまないがうちでそれやったら全部直させる
例にあがってるファイルなりソケットなりはクローズでエラーを返す可能性があるからダメ
そもそも昔のドキュメントには終了処理時にエラーの可能性がある場合はRAIIは適用外だってちゃんと書いてあったんだがなあ
いつのまにか戻り値無視する素人が増えてしまった

967 :デフォルトの名無しさん:2008/10/10(金) 02:59:54
cerrは凡ミスだな
しかし、言わんとすることは分かるだろ

C++言語の最初のレッスンでは、
「プログラムに書いた指示は意図通り処理されないことがある。
だから必ず失敗を恐れ、EXIT_FAILUREを返しなさい。
決してcatchを省略してはなりません。例外仕様を決めずに
コーディングを開始してはいけません。」と叩きこむ。これでOK。

968 :デフォルトの名無しさん:2008/10/10(金) 03:04:30
>>966
どっかで、デストラクタとclose(メンバ関数)の両方用意するのがいいって話を見たことがある。
無視していいときはデストラクタに任せ、戻り値が欲しければメンバ関数を明示的に呼ぶと言う具合。

969 :デフォルトの名無しさん:2008/10/10(金) 03:05:15
>>950
そのスレタイだと絶対荒れるw

まあこのスレでもなんでC++が肥大化したかはわからなかったが
信者の頭がおかしいことは分かった

970 :デフォルトの名無しさん:2008/10/10(金) 03:06:53
肥大化したのは単に禿が決めたことだから
一介の利用者がワーワー言った所で理解が及ぶべくもない

971 :デフォルトの名無しさん:2008/10/10(金) 03:12:52
もう1000ですね
間が空くたびに煽った甲斐がありました
擁護派の人たちは見てて楽しかったです^^

972 :デフォルトの名無しさん:2008/10/10(金) 03:16:49
>>969
事実そうなったからこそ、パート4まで続いている。

973 :デフォルトの名無しさん:2008/10/10(金) 03:24:53
>>971
埋め立てご苦労

974 :デフォルトの名無しさん:2008/10/10(金) 03:54:11
まぁ、世の中が本当に頭の良い奴ばっかりなら、C++以上の言語が作られそれが世界を席巻していたであろうw

975 :デフォルトの名無しさん:2008/10/10(金) 03:58:58
と、馬鹿が不毛な事を言っております

976 :デフォルトの名無しさん:2008/10/10(金) 07:00:20
どんなに彼が頑張っても && || が問題などという話はないという結論で

977 :デフォルトの名無しさん:2008/10/10(金) 08:32:04
>>976
>>799と前後の流れを10億回読み直せ
読み終わるまでメシも食うな

978 :デフォルトの名無しさん:2008/10/10(金) 08:59:04
なぜ799はこんなに必死なのか

979 :デフォルトの名無しさん:2008/10/10(金) 09:03:41
どっちもどっち

980 :デフォルトの名無しさん:2008/10/10(金) 09:15:35
【信者】C++の問題点【アンチ】
http://pc11.2ch.net/test/read.cgi/tech/1223597633/

981 :デフォルトの名無しさん:2008/10/10(金) 09:17:26
直球なタイトルだなw

982 :デフォルトの名無しさん:2008/10/10(金) 09:23:25
え、なに?スレ立てたの?馬鹿なの?

983 :デフォルトの名無しさん:2008/10/10(金) 09:31:21
便利そうだと思って拡張したらトラップだった
ってのがC++に多くて(例外なども)、その一例が&&であり、そこをピンポイントで養護しても意味をなさないっつーことでしょ。
言語としての整合性を考えて拡張しろと。
まあ、今更なんだけどね。
一旦なされた拡張が次で消えるとも思えない。

984 :デフォルトの名無しさん:2008/10/10(金) 09:35:58
あなたは○×言語の問題点を指摘されました
1)「おまえは○×言語もわからない馬鹿だから問題じゃない!」とレッテルを貼る
2)「その問題は俺は回避できるから問題じゃない!」と論点を摩り替える
3)「△□言語にも同じ問題があるから問題じゃない!」と論点を摩り替える
4)「〜〜という理由でそれは問題とは言えないのではないか?」と論理的に問題無いことを証明する
5)「確かにそこには問題があるね」と素直に認める
普通は4か5を選ぶと思うんだが、何故か123ばっかりだったね

985 :デフォルトの名無しさん:2008/10/10(金) 09:39:01
詭弁連レス…

986 :デフォルトの名無しさん:2008/10/10(金) 10:05:25
>>984
いやいや、&&は「普通使わないという理由でそれは問題とは言えないのではないか?」だったはず。
ちっとも論理的ではないが。

987 :デフォルトの名無しさん:2008/10/10(金) 10:25:18
まぁ信者は問題点に納得した時点で沈黙するからなぁ
結局新規の馬鹿信者が斜め上発言してアンチがフルボッコにするループはいくらでも続く

>>986
それ論点のすり替えに該当してるからw
証明というなら、そう在るべき理由とその重みを挙げるべき

988 :デフォルトの名無しさん:2008/10/10(金) 10:26:17
&&批判に反発してた連中は、終わった話を何度も蒸し返して
無駄に傷口広げてる感じだったな

しかも禿の仕様ミスであること自体は認めているから
まともに・論理的には反論できずに
そんなのは些細なことで問題にするほうがおかしいとか
斜め上の話ばかりになる

989 :デフォルトの名無しさん:2008/10/10(金) 10:31:40
信者とか擁護派とかアンチとか煽りはフィルターして読むと、自分にとってはなかなか実の
ある内容だった。
非常に気を付けて使う必要があるが、気を付ければ高い性能を得ることができることが
わかった。赤兎馬みたいなもんすね。

990 :デフォルトの名無しさん:2008/10/10(金) 10:35:32
ていうか、&& 批判を批判しているのはC++信者ですならないんですがw

991 :デフォルトの名無しさん:2008/10/10(金) 10:38:08
>>989
そんなプログラミングの勉強初めて1ヶ月経ちました!見たいな事言わんでもw

992 :デフォルトの名無しさん:2008/10/10(金) 10:39:43
仮に読むまで評価しない式の参照型を追加したらもっと凄い事になりそうだ

993 :デフォルトの名無しさん:2008/10/10(金) 10:57:01
初心忘るるべからず

994 :デフォルトの名無しさん:2008/10/10(金) 11:02:32
子供の発見には、満面の笑みで「へぇ!すごいねぇ!」って言ってあげるべきだったな

>>989
素晴しい着眼点だと思うよ!今後もがんばって研鑽してね!

995 :デフォルトの名無しさん:2008/10/10(金) 11:06:42
満面の笑みと言うなら

>>989
素晴しい着眼点だと思うよwwwwwww今後もがんばって研鑽してねwwwwwww

996 :デフォルトの名無しさん:2008/10/10(金) 11:06:50
あんま煽ってやるなよw

それと、赤兎馬の比喩に適切なのはどっちかっつうとCだな

997 :デフォルトの名無しさん:2008/10/10(金) 11:15:06
>>994=995
必死すぎのアンチにワラタ

998 :デフォルトの名無しさん:2008/10/10(金) 11:17:00
いや、つまんないから

999 :デフォルトの名無しさん:2008/10/10(金) 11:23:08
つまり、

1000 :デフォルトの名無しさん:2008/10/10(金) 11:23:50
C++最強。以上。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

213 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)