トップページ⇒tech
1001コメント278KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2008/08/28(木) 14:48:15
仕様が大きすぎるくせに、
実用的なライブラリが未整備。

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

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

C++はなんでもできます。でもなんにもできてないので
つくってね。的な。
0159デフォルトの名無しさん2008/09/21(日) 13:37:14
あ、言っておくと>>146とは別人で、Javaは論外です
0160デフォルトの名無しさん2008/09/21(日) 13:40:31
>>158
だからプロファイルを取ってタイムクリティカルな部分だけでも
C/C++で書けって言ってるんだよ。察しが悪いな。
0161デフォルトの名無しさん2008/09/21(日) 13:49:12
…それって結局、
> ホットスポットだけDLLで外出しすれば
と同じことだよね。
0162デフォルトの名無しさん2008/09/21(日) 13:50:41
まあそうだな
0163デフォルトの名無しさん2008/09/21(日) 13:54:06
要するにJavaは動作が遅いって認めてるわけだ
開発は早いけど

WindowsだけならC#使っちゃうな
Linux/UNIXならJava
0164デフォルトの名無しさん2008/09/21(日) 15:15:34
自分はC++が割りと好きだけど
あのコンパイルの遅さは糞だと感じる
これで開発効率が落ちてる
実行時の効率とのトレードオフなんだけど、でもなぁ
0165デフォルトの名無しさん2008/09/21(日) 15:56:22
precompiled header使える処理系使えばええやん
0166デフォルトの名無しさん2008/09/21(日) 16:04:52
パースに時間が掛かってるというよりも
テンプレートによるコンパイル時演算で時間が掛かるのでPCHじゃ解決しない
Boost.Function とか時間掛かるじゃない
Boost.Iterator とかも
0167デフォルトの名無しさん2008/09/21(日) 16:59:40
もうすべてHaskellで書いて未来の処理系のおまじないにすべてを託したい。
0168デフォルトの名無しさん2008/09/21(日) 17:48:40
C++使いこなせない奴ってかわいそうってとこまで読んだ
0169デフォルトの名無しさん2008/09/21(日) 17:54:23
>>155
>配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの

それってユーザー側の影響はないのではないかと？
0170デフォルトの名無しさん2008/09/21(日) 18:10:41
>>169
実行時の効率が結構違う
0171デフォルトの名無しさん2008/09/21(日) 21:08:41
現実の世界ではCの移植性が最高、次にだいぶ落ちるけどC++、Javaはもっとも移植性が低い
0172デフォルトの名無しさん2008/09/21(日) 21:31:48
JAVAってマルチプラットフォームじゃなかったの？
0173デフォルトの名無しさん2008/09/21(日) 21:43:40
Javaも動かないものは動かないしな。
原因がプログラムが悪いにしろなんにしろ、ランエニホエアとかを
売りにしてたから、がっかり度が大きい
0174デフォルトの名無しさん2008/09/21(日) 21:53:22
>>173
いやいや、Java VMが移植されてない環境では動かないという意味だと思う
0175デフォルトの名無しさん2008/09/21(日) 22:59:16
それと現実的な実行スピードとサイズもCが一番優れてるよな
0176デフォルトの名無しさん2008/09/21(日) 23:04:31
>>175
結局のところCを完全に越えた言語がないってことだろ
だから、C++,JAVA,C#,Objective-CなどのようなC言語の派生でうろうろしている
DはCの派生言語の整理かつ集大成にしようとしているようだが、
移行するほどの利点がない
0177デフォルトの名無しさん2008/09/21(日) 23:58:24
>>173
結局UNIXとWindowsじゃ要求されるものが違いすぎて
そもそも要求の次元からして殆どの分野で同じものじゃ済まされないんだよな
JAVAあほす
0178デフォルトの名無しさん2008/09/22(月) 00:00:24
Cの移植性ってWIN32APIとかはどげんすると？
0179デフォルトの名無しさん2008/09/22(月) 02:55:49
Objective-CなんてC++と同等に並べんなよ。原住民の言語じゃねーか。
C#もエスペラント語みたいなもんだろ。綺麗だけど流行っちゃいねえ。
0180デフォルトの名無しさん2008/09/22(月) 04:53:47
お前の中では8年前で情報が止まってるんだなｗ
0181デフォルトの名無しさん2008/09/22(月) 06:52:46
お前は8年間妄想してたんだな。Objective-Cでパンは食べれたかい？
0182デフォルトの名無しさん2008/09/22(月) 07:22:33
いやあのC#の話なんですが
0183デフォルトの名無しさん2008/09/22(月) 15:10:11
Objective-Cは神
0184デフォルトの名無しさん2008/09/22(月) 21:07:27
一方、ベルギーの音楽ソフトメーカーは日本人を雇った
ttp://www.flstudio.com/documents/flchan.html
0185デフォルトの名無しさん2008/09/23(火) 14:08:51
Objective-Cは神

つまり糞の役にも立たない
0186デフォルトの名無しさん2008/09/23(火) 18:57:40
例えば C++ のどの機能を削れるの？
0187デフォルトの名無しさん2008/09/23(火) 19:30:02
マクロを削ろう。
ストローのおじさんもマクロを削りたいみたいだし。
0188デフォルトの名無しさん2008/09/23(火) 21:41:24
全部の機能を削ればいいと思うよ
そうすれば、移植性が最高、実行速度もトップレベル、バイナリサイズも小さい、しかも習得が容易な言語になる
0189デフォルトの名無しさん2008/09/23(火) 22:01:52
Cコンパイラの移植性とネイティブの実行効率が欲しいだけなら
Cソースにコンパイルすればいいんですよ
昔のC++、eiffelやsatherのようにね
0190デフォルトの名無しさん2008/09/23(火) 22:13:02
昔のC++からCへのトランスレータには例外とかRTTIないでしょ
そのへんちゃんとしてるのある？
0191デフォルトの名無しさん2008/09/23(火) 22:40:00
>>190
>>188
0192デフォルトの名無しさん2008/09/23(火) 22:51:53
>>188
ばーか
0193デフォルトの名無しさん2008/09/23(火) 22:58:18
>>190
eiffelもsatherも例外ぐらい当たり前のようにあるはずだよ
0194デフォルトの名無しさん2008/09/23(火) 23:05:07
さらに C 言語から switch 文、for 文のように必要ない機能を削れば移植性が高くて
学習しやすい言語になるよ。
0195デフォルトの名無しさん2008/09/23(火) 23:10:01
>>190
例外もRTTIも自前で実装できない人の発言。
例外なんてジャンプテーブルをスタック状に積み重ねるだけだし、RTTIなんてvtableのアドレスをそのまま使えばいいだけ。
0196デフォルトの名無しさん2008/09/23(火) 23:12:58
>>194
C言語からswitchとforを削って移植性が高くなるのは、
その仕様の処理系がC言語の処理系より多くの環境にある場合だけだね
0197デフォルトの名無しさん2008/09/23(火) 23:30:53
>>196
C言語のサブセットだからすでにC言語の処理系と同じ数の処理系があると考えていい。
0198デフォルトの名無しさん2008/09/23(火) 23:32:18
同じ数の処理系なら移植性は同じっていってるんじゃん
0199デフォルトの名無しさん2008/09/23(火) 23:46:40
サブセットの方が処理系が多いし、単純な仕様のほうが移植性が高いんじゃないの?
0200デフォルトの名無しさん2008/09/23(火) 23:51:04
>>194
つまんね
0201デフォルトの名無しさん2008/09/23(火) 23:54:05
現実にそんな処理系があるなら移植性は高いけど
でもC言語からswitchとforを削った処理系がある？無いよね？
だからそのサブセットは普通のCと比較して実際の移植性は同じだってこと
いま世の中に存在しない夢のコンパイラは比較対象にならない
0202デフォルトの名無しさん2008/09/24(水) 00:01:14
>195
cfrontと禿はそれが現実的なコストで出来ないって判断したよ
つか、自前で実装って、毎回ターゲットの環境用に書くんだから移植性は最低だよね
0203デフォルトの名無しさん2008/09/24(水) 00:02:27
>>194
ifやwhileなどで置き換えができるからいらないっていう主張なら、関数定義と？と末尾再帰だけでＯＫになってしまうぞ
0204デフォルトの名無しさん2008/09/24(水) 00:09:22
>>194
使いにくくなっちゃうけどね
02051952008/09/24(水) 04:17:19
>>202
もっとわかりやすく。D&Eかなんかのページ数でもいい。
または、移植性最悪だからといってポーティングを諦めた処理系があるなら教えてくれ。
0206デフォルトの名無しさん2008/09/24(水) 04:51:33
正直、例外は好きじゃない。
0207デフォルトの名無しさん2008/09/24(水) 08:42:09
Maybeを使うんですか
0208デフォルトの名無しさん2008/09/24(水) 09:01:13
>205
ここまでの流れをまとめると
>188 C言語最高
>189 ならC++からCへのトランスレータを使えばいいんじゃね？
>190 でも例外とかRTTIとかモダンな仕様を満たすトランスレータは無いよね？
>195 例外とRTTIくらい自前で実装しろ、雑魚
>202 禿もトランスレータでは現実的に無理って判断したよ？
0209デフォルトの名無しさん2008/09/24(水) 10:15:23
>>195
移植性の話をしてる時に自前で実装すればいいって発言はありえない
0210デフォルトの名無しさん2008/09/24(水) 11:41:49
>>205
スタック操作がからんだら移植性が失われるのは当たり前。阿呆か。
0211デフォルトの名無しさん2008/09/24(水) 20:23:42
C++は、C言語がそれほど変わらず存在し続ける為の生け贄。UNIXが存在する限りこの連鎖は断ち切れん。

未来永劫C++はC言語の為に拡張され続ける運命にある、．．．．．．．．．．．．．．．．．．．．．．．．．．たぶん、
0212デフォルトの名無しさん2008/09/24(水) 22:36:57
C++信者って195みたいなのばっかりなの？
0213デフォルトの名無しさん2008/09/24(水) 22:44:13
C++信者なんていませんよ。
ファンタジーじゃあるまいし。
0214デフォルトの名無しさん2008/09/24(水) 23:08:17
195はファンタジーかよ
0215デフォルトの名無しさん2008/09/24(水) 23:10:55
C++がファンタジーになる時代はいつですか？
0216デフォルトの名無しさん2008/09/24(水) 23:24:31
C++標準化委員会が「新しい機能はなるべく付け加えるな」と
言い続けてこれだからなあ

PGの欲望っていうのはとどまる所を知らない
0217デフォルトの名無しさん2008/09/25(木) 01:13:17
C++なんてコンピュータを制御するための設定ファイルですよ。
0218デフォルトの名無しさん2008/09/25(木) 02:32:04
C++ってそんなにダメか?

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

実験程度ならmatlabやjavaでもいいけど、スピード命ならC/C++に適わない
まあC++でなくても、Cで済むんだけど、規模が大きいときや、
フィルタを組み合わせたいとき、C++の方が記述が楽になる
0219デフォルトの名無しさん2008/09/25(木) 04:10:09
++とか一般人に分からない演算子使うのやめて
C 2.0に名前変えるべき
0220デフォルトの名無しさん2008/09/25(木) 06:21:41
むしろすべてC++でいいと思う。最近似たような言語が増えて効率悪すぎ。
0221デフォルトの名無しさん2008/09/25(木) 08:06:11
配列とポインタは明確に区別するべきであった。
何故一つ余計に&付けるのをケチったんだ。
0222デフォルトの名無しさん2008/09/25(木) 09:03:26
>>218
C++がどうしようもなくダメってわけじゃなくて
CとC++を明確に区別して比較したらC言語の方がより良いってことでしょ
0223デフォルトの名無しさん2008/09/25(木) 10:03:46
>>221
配列とポインタを同列に扱えるのがC/C++の強み。
嫌なら使うな。
0224デフォルトの名無しさん2008/09/25(木) 10:25:46
>>222
>C言語の方がより良い
誰にとって、どういう点で「良い」つってんだお前は。
0225デフォルトの名無しさん2008/09/25(木) 10:44:56
188からの流れ読んだら？
移植性とか実行時の効率とか学習コストの点で「良い」んだろ
まあ個人的には速度に関しては有意な差は無いと判断するけどな
0226デフォルトの名無しさん2008/09/25(木) 11:12:26
初期コストが低くてもその後ずっと開発コストが高かったら意味ないだろ。
開発コストが低くてもエンドユーザで実行コストが高かったら意味ないだろ。
C++ が最適
0227デフォルトの名無しさん2008/09/25(木) 11:19:17
１〜２行目と３行目に関連が無い
これがファンタジーってやつかｗ
0228デフォルトの名無しさん2008/09/25(木) 11:50:19
>>225
>188からの流れ
そっからかよｗ
強引な言い訳だな。
0229デフォルトの名無しさん2008/09/25(木) 11:57:55
ごめんな
言い訳じゃないんだけど>>208にまとめがあったからつい…
0230デフォルトの名無しさん2008/09/25(木) 12:25:28
ばかばっか
0231デフォルトの名無しさん2008/09/25(木) 12:43:12
>>227
いちいち説明を書かないと関連性が分からない
めんどくさいやつだな
0232デフォルトの名無しさん2008/09/25(木) 18:18:26
いや、関連性は無いぞ。
C++が優れていると主張したいならもっと客観的・論理的な視点を持ってくれ。
226の場合はまず、開発コストという、あいまい且つ広範囲な言葉を使うのをやめて、
もっと定量化可能な別のものさしを定義する必要がある。
次にそれを測定し比較、さらに開発コストとそれ以外のメリットデメリットを比較検討、
その結果C++が最適だと主張するなら構わない。
それを行わず「C++最適」の一点張りでは信者は盲目だと思われても仕方が無いな。
0233デフォルトの名無しさん2008/09/25(木) 18:19:38
長い。
3文字でまとめてくれ。
0234デフォルトの名無しさん2008/09/25(木) 18:23:19
無関連
0235デフォルトの名無しさん2008/09/25(木) 18:23:22
信
者
乙
0236デフォルトの名無しさん2008/09/25(木) 18:44:40
な
お
ガ

…どうでもいいですが、C++ を More C として使う発想のない人がいますね。
0237デフォルトの名無しさん2008/09/25(木) 18:52:53
そんな使い方つまらないから
0238デフォルトの名無しさん2008/09/25(木) 18:57:16
BetterじゃなくてMoreなのかよｗｗｗｗ
さすがC++信者、その発想はなかったわｗｗｗｗ
0239デフォルトの名無しさん2008/09/25(木) 20:18:14
俺は自分でプログラム書くときは C++
しかし、外部の業者に仕様書出して作ってもらうときは原則C
C++でかかれたひどいプログラムは見るに耐えない
0240デフォルトの名無しさん2008/09/25(木) 22:14:12
型チェックに厳しいところだけでも C++ の方が良いと思うが、もしかして C99 で同レベルになってたりする？
0241デフォルトの名無しさん2008/09/25(木) 22:47:28
CINTで開発したら、コンパイル頻度へってええぞー。
0242デフォルトの名無しさん2008/09/26(金) 00:51:49
少なくともUNIX界では一部のtkが使ってる程度のニッチ言語
0243デフォルトの名無しさん2008/09/26(金) 01:00:47
UNIXだとやはりCなのかね
0244デフォルトの名無しさん2008/09/26(金) 02:32:28
GNUとかも大体Cだと思う。
プロジェクト管理ツールのsubversionはCでした。

FireFox3は大体C++でした。
0245デフォルトの名無しさん2008/09/26(金) 07:57:31
>>242 Be…
0246デフォルトの名無しさん2008/09/26(金) 09:54:54
>>240
C99はその辺の仕様は変わってない。
どっちかってーと、便利な方向に拡張されてる印象。
(複合リテラルとか可変引数マクロとか)
0247デフォルトの名無しさん2008/09/26(金) 10:34:37
いま全部読みなおしたけど意外と良スレ
ただもうちょっとまともなC++擁護派の意見が欲しい
0248デフォルトの名無しさん2008/09/26(金) 11:05:10
Mozillaのドキュメント読むとアレはもはやC++とは呼びたくない代物だ
まあ確かにC++の可搬性は低いと認めざるを得ないな

C99は独自拡張の現状追認(inlineとか)と可搬性向上(int32_tとか)
それとブロック途中で変数宣言が出来るようになった(C++から逆輸入)
あとC99とC++とは互換性がない
（まあ常識的な範囲では大丈夫だし、すぐに仕様を取り込むだろうけど）
0249デフォルトの名無しさん2008/09/26(金) 12:16:44
結構Ｃも変化してきてたんだな。
0250デフォルトの名無しさん2008/09/26(金) 13:05:10
C でプログラム書いている人って忍耐強いね。
C++ を覚えてから C でプログラムを書くなんて考えられなくなった。
Ruby を覚えて凄く便利だと思ったけど C++ とは役割が違うので C++
は捨てられません。
0251デフォルトの名無しさん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
など
0252デフォルトの名無しさん2008/09/26(金) 15:19:17
OS の API を COM 風のインタフェースにすればよかったのに。
0253デフォルトの名無しさん2008/09/27(土) 22:39:54
C++はほかのプロセスにクラスオブジェクトを送ろうとするだけで困難に直面するからなぁ。
0254デフォルトの名無しさん2008/09/27(土) 22:52:27
それはアラインメントの問題じゃなくて？？
だとするとCで構造体送っても同じだと思うけど。
0255デフォルトの名無しさん2008/09/27(土) 23:01:28
vtable付き構造体を別プロセスに送るのは、そもそも無茶ではなかろうか
0256デフォルトの名無しさん2008/09/27(土) 23:14:43
一般的な OS だと vtable 付きに関わらず別プロセスに送れないんじゃない？
0257デフォルトの名無しさん2008/09/28(日) 02:42:11
>>253はマヌケな指摘！

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