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

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2008/08/28(木) 14:48:15
仕様が大きすぎるくせに、
実用的なライブラリが未整備。

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

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

C++はなんでもできます。でもなんにもできてないので
つくってね。的な。
0002デフォルトの名無しさん2008/08/28(木) 14:49:56
C++0xに期待っ（決めっ！）
0003デフォルトの名無しさん2008/08/28(木) 14:51:00
あぁ。なんか変なコピペが入っちゃったｗ
0004デフォルトの名無しさん2008/08/28(木) 15:01:31
wikipediaのC++0xのページ読んで
吐き気がしてきたｗ

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

C++というPerlといい。
0005デフォルトの名無しさん2008/08/28(木) 16:40:39
必要とされるものを追加した結果だろ。
未踏叩き厨によればw
0006デフォルトの名無しさん2008/08/28(木) 21:52:09
読んだことないならC++の設計と進化をぜひ。
そういう仕様になった理由がいろいろ書いてあって、同情できる。
だからと言って、C++が良くなるわけではないけれど。
0007デフォルトの名無しさん2008/08/28(木) 21:55:36
Unix原典とかねｗ
役には立たないけど怒りを抑える効果はある
0008デフォルトの名無しさん2008/08/29(金) 06:07:18
MS-DOSのTurbo C++ 3.0のころが
一番素直だった。

あるのはクラスと継承とカプセル化程度。
例外はない。STLはない。当然Boostなんてものもない。
きわめてシンプルなオブジェクト指向言語だった。
0009デフォルトの名無しさん2008/08/29(金) 08:34:48
C++が無かったら他の言語のコンパイラやインタプリタの作成も不可能になる
0010デフォルトの名無しさん2008/08/29(金) 09:33:50
>>9
Cがあるって言い返されちゃう。
0011デフォルトの名無しさん2008/08/29(金) 10:17:32
>>4
C++は勉強用の言語じゃない。超実務用。職人用の道具みたいなもん。
Stroustrup氏がはっきりそう言い切ってる。
0012デフォルトの名無しさん2008/08/29(金) 13:15:28
C++が無かったらWindowsも無くなっちゃうな。
0013デフォルトの名無しさん2008/08/29(金) 21:07:39
巨大なクラスライブラリがくっついてくるJavaとかC#に比べると
むしろ機能が足りなさすぎるんだが。
この程度でどこが肥大化って感じるんだ？
0014デフォルトの名無しさん2008/08/29(金) 22:54:11
そしてJavaもC#も結局C++で書かれてるんだよね。
0015デフォルトの名無しさん2008/08/31(日) 03:20:29
まともな C++ の参考書の厚さは異常。
逆に言うと、薄い参考書は当てにならない。
0016デフォルトの名無しさん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エピソード２」
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 その２」
http://www.youtube.com/v/2bJYmIDWrqY, 05:16,[KORG DS-10]はじめてのシーケンサー
http://www.youtube.com/v/Usjy626gQYQ, 05:21,[KORG DS-10]はじめてのシーケンサー（修正版）
0017デフォルトの名無しさん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エピソード２」
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 その２」
http://www.youtube.com/v/2bJYmIDWrqY ,05:16,[KORG DS-10]はじめてのシーケンサー
http://www.youtube.com/v/Usjy626gQYQ ,05:21,[KORG DS-10]はじめてのシーケンサー（修正版）
0018デフォルトの名無しさん2008/09/08(月) 09:29:21
＞実用的なライブラリが未整備。

独自仕様で90%のパソコンで動くライブラリと、その後から出来た
標準規格で誰も使いたくないクソ設計のライブラリがある。
0019デフォルトの名無しさん2008/09/08(月) 11:28:58
>>18
実用的なライブラリが未整備って事じゃん
0020デフォルトの名無しさん2008/09/08(月) 15:07:06
でも C++ を使うのは面白いよー。
BASIC から C 飛ばしていきなり C++ に行ったけど
こんな面白い言語は他にないよー。ひゃっはー。
0021デフォルトの名無しさん2008/09/08(月) 17:34:03
boostのmplやマクロを多用して何言語がよくわからない事をするのが楽しそうですね
0022デフォルトの名無しさん2008/09/08(月) 21:43:19
C++の実用ライブラリなんていくらでもあるじゃん。
たんに知らないだけだろ。
0023デフォルトの名無しさん2008/09/09(火) 11:31:48
javaだのC#みたく標準ライブラリじゃなきゃわかりません><
てことだろ。
0024デフォルトの名無しさん2008/09/09(火) 13:40:20
javaもGUIは標準じゃないだろ。いや、標準じゃないものを使うのが当たり前になっているのかも知らんが。
0025デフォルトの名無しさん2008/09/09(火) 14:22:15
AWTって標準じゃないの？
0026デフォルトの名無しさん2008/09/09(火) 16:59:15
iostreamの気持ち悪さは以上
0027デフォルトの名無しさん2008/09/09(火) 18:57:54
>>22
実用的なライブラリが未整備って事じゃん
0028デフォルトの名無しさん2008/09/09(火) 19:06:29
例えば、どんなライブラリが欲しいのかしら？
0029デフォルトの名無しさん2008/09/09(火) 19:20:22
メモリリークせず、バッファオーバーランせず、スレッドセーフで、ドキュメントが充実していて
3ステップ以内で大抵のやりたい事ができて、高速で、導入の手間が掛からず
移植性に優れていて、十分に枯れている

そんな実用的なライブラリが欲しいです
0030デフォルトの名無しさん2008/09/09(火) 19:24:20
スレッドセーフじゃないのはもうあきらめるしか。
C#でどうですか？
0031デフォルトの名無しさん2008/09/09(火) 20:24:54
しーぷらぷらしーえるあい
0032デフォルトの名無しさん2008/09/09(火) 20:29:29
>>26
あれでも、昔の仕様よりゃかなりマシになってんだぞｗ
0033デフォルトの名無しさん2008/09/09(火) 20:54:55
iostreamはC++の"入門書"で真っ先に出てくるのが
今思い返すとウザかったなぁ・・・・。
<<演算子のオーバーロードとか、「C++自体がそういう文法」だと錯覚させられた。
0034デフォルトの名無しさん2008/09/09(火) 22:12:18
C#なんかは言語よりもランタイムのリフレクションやコード動的生成の機能に頼る方向だよね
0035デフォルトの名無しさん2008/09/10(水) 17:26:47
びよ～んすとらうすとらっぷ
0036デフォルトの名無しさん2008/09/10(水) 17:55:18
>>34
だってJavaモドキだもん
0037デフォルトの名無しさん2008/09/10(水) 19:01:35
>>29
ライブラリの範疇超えた要求だしなぁ。
0038デフォルトの名無しさん2008/09/10(水) 19:46:56
>>37の定義するライブラリの範疇って何よ
0039デフォルトの名無しさん2008/09/13(土) 11:37:20
クラスとSTLの相性の悪さが・・・

クラスの中でSTLを使うってだけならいいんだが、
設計そのものに適用しようとするともうぐちゃぐちゃ
0040デフォルトの名無しさん2008/09/13(土) 11:57:25
んなことねーべ
STLの根幹であるコンセプトってのはオブジェクト指向の根底にもあるもんだし
0041デフォルトの名無しさん2008/09/13(土) 12:20:50
>>39
あんたがSTLを使い慣れてないだけ
0042デフォルトの名無しさん2008/09/13(土) 17:59:59
信者がこんなんだから進歩しないのよ
0043デフォルトの名無しさん2008/09/13(土) 18:28:32
で、C++は難しいからPHPでも使うかって？
0044デフォルトの名無しさん2008/09/13(土) 18:35:32
>>42
違う
原因は互換性っていう過去の柵が8割以上を占めてると思う
0045デフォルトの名無しさん2008/09/13(土) 19:26:18
互換性ない俺様言語作るのは簡単だからね
0046デフォルトの名無しさん2008/09/13(土) 19:34:01
D言語にとって変わられればいいじゃん。
とか思ってたけどD言語迷走しすぎ。
0047デフォルトの名無しさん2008/09/13(土) 20:13:12
Cと互換性のない言語はかわりにはならんし別物になっちゃうんだよなあ。
0048デフォルトの名無しさん2008/09/13(土) 20:15:26
Objective-Cの方が良かったんだけどね
0049デフォルトの名無しさん2008/09/13(土) 21:31:12
STLってゆうか、テンプレートなんだけど、
テンプレート化したクラスにおいて、別の種類の柔軟性を持たせたくなって仮想関数を
作りたくなるときってないですか? それって無理ですよね?
そんなこと思う事自体が何か間違ってるんでしょうか。
0050デフォルトの名無しさん2008/09/13(土) 22:18:14
>>49
クラステンプレートに仮想関数を持たせることはできるよ。
メンバテンプレートで仮想関数は無理だけど。
0051デフォルトの名無しさん2008/09/14(日) 10:42:46
世の中の天才PGみてるとC++なんて使わずC使ってるからなぁ
0052デフォルトの名無しさん2008/09/14(日) 10:46:01
天才だからCとかアセンブラで十分なんだよ
その人達みたいにCを使いこなすよりはC++をそれなりに使えるようになる方がまだ簡単
0053デフォルトの名無しさん2008/09/14(日) 11:28:46
天才は1人でシステム開発するでしょ。だからCで十分なんだよ。
0054デフォルトの名無しさん2008/09/14(日) 11:55:23
少人数の開発に向いてるのはLisp
0055デフォルトの名無しさん2008/09/14(日) 12:13:14
ほとんどの場合、Cでいいよね
C++とかJavaとかって、無駄にクラスを作ったり無駄にソースコードを
増やして、開発量水増しするために使うもんだと思ってる。
0056デフォルトの名無しさん2008/09/14(日) 12:21:26
本気で言ってるのかマジレスなのか非常に気になるが・・・・
オブジェクト指向の言語の必要性を感じてないんか？

それからC++はマルチパラダイム言語と呼ばれるように
非常に懐の広い言語なんだが
0057デフォルトの名無しさん2008/09/14(日) 12:34:59
tmpによる静的モデル検証とか使い熟せれば便利だと思う
言語内DSLなんていまじゃ別に奇なものでないしね
あと名前空間とか激しく便利だね、XXX_YYY_ZZZとか書かなくてすむし

でもSTL, boost, TMPとか使わずにC++使うぐらいならC99の方が100倍マシだ
0058デフォルトの名無しさん2008/09/14(日) 17:29:57
そもそもC++が幅利かせてるのってwindowsくらいだろ。
UNIXの世界じゃたんなる一選択肢的な感じだし。
0059デフォルトの名無しさん2008/09/14(日) 17:37:00
>>56
単にオブジェクト指向っぽくすることだけが目的になってない？
なんのためのオブジェクト指向か分ってる？
0060デフォルトの名無しさん2008/09/14(日) 17:41:46
マルチパラダイムと称して
いきあたりばったりに機能拡張した感が否めない
0061デフォルトの名無しさん2008/09/14(日) 18:49:18
>>56
C++は書く人がOOPを意識して書けばOOPになるってだけで
実際には>>55のような工数の水増しのネタにされているんだろうなぁ
0062デフォルトの名無しさん2008/09/14(日) 19:27:14
なんにでも使えるものはなんの役にも立たないってやつ？
0063デフォルトの名無しさん2008/09/14(日) 19:28:35
Javaほど急速じゃないけどCOBOL化が着々と進んでる気がする。
0064デフォルトの名無しさん2008/09/14(日) 20:17:42
むしろC++がノロノロと次世代の仕様を作成している間にJavaがここまで肥えるとは思わなかった
0065デフォルトの名無しさん2008/09/14(日) 20:43:25
まぁあんだけ群がればピザりまくるに決まってる
0066デフォルトの名無しさん2008/09/14(日) 21:47:41
>>62
その状態になっていると思う
0067デフォルトの名無しさん2008/09/14(日) 22:02:54
塩は料理から凍結防止ガラス作りまでなんにでも使えるよ。
0068デフォルトの名無しさん2008/09/14(日) 22:34:49
Objective-C > C++
0069デフォルトの名無しさん2008/09/14(日) 22:37:32
まっかさんはどっかいってね
0070デフォルトの名無しさん2008/09/14(日) 22:50:00
オブジェクト指向度マップ

<--- 構造化　オブジェクト指向 --->
C　C++　Java　C#　OC　Smalltalk
0071デフォルトの名無しさん2008/09/14(日) 22:59:56
スモールトークに需要あるのー
0072デフォルトの名無しさん2008/09/14(日) 23:39:00
えいふぇるはどの辺に位置するの？
0073デフォルトの名無しさん2008/09/15(月) 00:00:54
実際に Smalltalk に需要があるかどうかは関係なく、
・実行時にメッセージスロットを検索に行く
言語の代表として、歴史的な経緯から使われているに過ぎないのだろう。
Self とか Lua とか JavaScript でも文脈としては問題ないが、先輩に応分の敬意を払わないと非難を受けることだろう。
表面の文法の問題ではないということね。
0074デフォルトの名無しさん2008/09/15(月) 00:30:00
>>69
Objective-C >>>>> C++
0075デフォルトの名無しさん2008/09/15(月) 01:05:26
すごいね
0076デフォルトの名無しさん2008/09/15(月) 01:36:54
初心者向け度って意味ね
0077デフォルトの名無しさん2008/09/15(月) 06:21:16
C++0xになったらそろそろ標準の文字列クラスぐらい出てきますよね。
0078デフォルトの名無しさん2008/09/15(月) 07:38:39
完全なコンパイル言語でオブジェクト指向やろうとするとC++が限度ってこと。
OCなんてC+オブジェクト指向インタプリタだし。
0079デフォルトの名無しさん2008/09/15(月) 11:53:25
>>77
相変わらずstd::basic_stringです。
0080デフォルトの名無しさん2008/09/15(月) 13:37:13
>>78
それに加えて C とある程度の互換を持たせるという縛りもきつ過ぎる
0081デフォルトの名無しさん2008/09/15(月) 17:12:29
そもそもSTL理念に必要最低限って書いてあったけど。
JAVAやドトネト並みの網羅されたクラスライブラリがあるだけでぜんぜん違うのに
0082デフォルトの名無しさん2008/09/16(火) 21:41:32
でもでかいランタイムが必要だと選択肢から外れちゃうよ
0083デフォルトの名無しさん2008/09/17(水) 21:43:17
>>82
それは人それぞれなのでは？
0084デフォルトの名無しさん2008/09/17(水) 22:16:09
>>83
当然そうだよ
ターゲットの環境や用途等にもよるし
0085デフォルトの名無しさん2008/09/18(木) 00:18:59
>>82が結局何を言いたいのかが分からない
0086デフォルトの名無しさん2008/09/18(木) 04:11:14
そりゃそのライブラリのために30MBのDLLが必要だったら困るじゃんって話でしょ。
再配布のライセンスとか、インストールが必要なのかとか他のアプリに影響与えないか
とかも重要だし。
0087デフォルトの名無しさん2008/09/18(木) 07:50:55
巨大なライブラリがあればもっと可能性が広がるのにって言ってる相手に
それは使えない可能性もあるって言ってなんか意味あるの？
0088デフォルトの名無しさん2008/09/18(木) 08:07:26
boostも便利なんだけどさ、amazonにSOAPで繋げて商品情報をGUIで一覧表示したいんだけど、
とか思うとまったく機能が足りてないんだよなあ。
0089デフォルトの名無しさん2008/09/18(木) 20:07:10
WTLとか、iostream使ったソケットプログラミングとか、
やろうと思えばいろいろ発展できそうなのにいまいちまとまりがない。
それが++
0090デフォルトの名無しさん2008/09/18(木) 20:11:50
大きくなると、まとまりがなくなるのは
どんな言語にもある。
0091デフォルトの名無しさん2008/09/18(木) 21:37:33
>>87
その大きさが可能性を狭めることもあるって言ってるんでしょ
0092デフォルトの名無しさん2008/09/18(木) 23:30:47
>>91
馬鹿なの？
0093デフォルトの名無しさん2008/09/18(木) 23:38:26
馬鹿はお触り禁止
放置しましょう
0094デフォルトの名無しさん2008/09/18(木) 23:43:34
>>91の何がおかしいかがわからないので教えてください
0095デフォルトの名無しさん2008/09/19(金) 00:02:15
>>81からの流れを例えで表すと

>>81　巨大重機(ライブラリ)があればビル建てるときも楽になるのにね
>>82　でもそんな巨大だと民家建てる時に困るじゃん
>>83　そんなの当たり前じゃないの？
>>84　当たり前だよ
>>85　結局>>82はそんな当たり前の事言いたかったの？
>>86　だから>>82は巨大重機じゃ民家建てる時に困るって言ってるんだよ
>>87　だからそんな当たり前の事言って何の意味があるの？
>>91　だから大きいと困る可能性もあるって言ってるんでしょ
>>92　馬鹿なの？
0096デフォルトの名無しさん2008/09/19(金) 00:13:32
ああなるほど
言語と一体化したようなライブラリでなければ>>95のような話だね

昔のVBや現在のドットネットを選択肢から外す状況を想定してた
0097デフォルトの名無しさん2008/09/19(金) 00:34:44
>>82はクラスライブラリが欲しいって話から
何時の間にか言語仕様上巨大なランタイムが必須ってとこまで飛躍してたのな。
そんなことしたらC++の存在意義が無くなるだけじゃんｗ
0098デフォルトの名無しさん2008/09/19(金) 02:23:31
C/C++だってランタイムは必要だぜ。
ライブラリモジュールを、配布プログラムに必ず含めなければならないとなれば大きいのは困るけど、
基本モジュールは別途インスコしておいて、アプリはそいつ必要に応じてリンクするのがやっぱりベストな気がするな。
OS以外の基本モジュールはNGなんて環境は相当特殊だろうし。
0099デフォルトの名無しさん2008/09/19(金) 03:23:43
Vista64bit使ってると.NETのありがたみが分かってくる。
一部のプログラム以外、.NETのほうが便利だし、
わざわざ32bit, 64bitとリリースを分けるまでもなく
VMが適当に最適化を行ってくれる。

C:\Program Files (x86)\フォルダに入ることもない。
0100デフォルトの名無しさん2008/09/19(金) 11:31:11
結局C言語と.NETがあれば十分じゃね？
C++はもう休めばいいよ
0101デフォルトの名無しさん2008/09/19(金) 11:42:16
携帯とかゲームとか組み込みとか色々あるから
ちっとも十分じゃない
0102デフォルトの名無しさん2008/09/19(金) 11:45:58
嫌C++厨必死ｗｗ
現実を見ろよ
どこのコンパイラメーカもC++無しでは食っていけない
0103デフォルトの名無しさん2008/09/19(金) 14:40:34
必死さで言うと･･･いやなんでもない
0104デフォルトの名無しさん2008/09/19(金) 15:22:13
醜いC++がしぶとく生き残る様は丁度アーキテクチャが汚い
x86がしぶとく生き残る様子に似ているかもしれない
0105デフォルトの名無しさん2008/09/19(金) 18:03:22
>>81
http://pc11.2ch.net/test/read.cgi/tech/1206447234/
0106デフォルトの名無しさん2008/09/19(金) 18:07:47
>>81
つ[D&E]
0107デフォルトの名無しさん2008/09/19(金) 18:33:01
D&Eはただのいいわけ本
ページを捲るたびに「ハイハイワロスワロス」って感想しか出てこない
0108デフォルトの名無しさん2008/09/19(金) 18:40:48
と言語の一つも設計した事のないカスがほざいております
0109デフォルトの名無しさん2008/09/19(金) 18:45:31
OS選ばないのが前提。
0110デフォルトの名無しさん2008/09/19(金) 19:02:10
java…
0111デフォルトの名無しさん2008/09/19(金) 23:40:26
>>104
C++が醜いですか？
たとえば何が綺麗なの？

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

共通点は、捨てるのが怖いほど既に投資してしまったこと
0112デフォルトの名無しさん2008/09/20(土) 01:14:28
x86の機械語体系は確かにグチャグチャだが、ハードウェア
アーキテクチャに限定して話をすれば80386以降は比較的
まともになったと思うよ。
0113デフォルトの名無しさん2008/09/20(土) 07:20:22
Alpha最高
0114デフォルトの名無しさん2008/09/20(土) 17:39:43
AMD64 はすっきりしたんじゃない？
0115デフォルトの名無しさん2008/09/20(土) 18:49:12
AMD（笑）
0116デフォルトの名無しさん2008/09/20(土) 21:48:29
C++最大の成功と失敗はCとの互換性だなあ。
あと時代が古いせいでいろんな事情を言語に載せてしまったように思える。

だからDはもうちょっとがんばって安心して使用できるように配慮してほしい。
0117デフォルトの名無しさん2008/09/20(土) 21:50:28
ああそれなら心配いらない
D言語なんて「絶対に」マイナーなままで終わるから
0118デフォルトの名無しさん2008/09/20(土) 22:08:50
MSは結構力入れて開発してるみたいだし
C#並にはメジャーになるかもよ
0119デフォルトの名無しさん2008/09/20(土) 22:10:24
ソースplz
いつの間にDigitalMarsとM$が手を組んだんだ
0120デフォルトの名無しさん2008/09/20(土) 22:17:03
昨日路地裏でキスしているところを見たよ！
0121デフォルトの名無しさん2008/09/20(土) 22:20:40
M$とTRONの坂村は手を組んだんだがな
0122デフォルトの名無しさん2008/09/20(土) 22:21:57
>>120
けしからん。スグにGoogleに削除要請だ！
0123デフォルトの名無しさん2008/09/20(土) 22:58:34
>>117
そうなのかな？
C++が肥大化しすぎているし、ネイティブ言語でまともなものが欲しいと言う需要もあるのでは？
今のところオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。
0124訂正2008/09/20(土) 22:59:13
>>123
今のところネイティブのオブジェクト指向言語でまともなものと言えば、Objective-Cくらいしかないのではないかと。
0125デフォルトの名無しさん2008/09/20(土) 23:04:10
ま、マイナーが好きな奴には性癖なんだから何も言わんよ
でもC++がこれだけ流通している理由も考えてみてくれ
たまにでいいから
0126デフォルトの名無しさん2008/09/20(土) 23:55:58
>>123
マカー乙
0127デフォルトの名無しさん2008/09/21(日) 00:06:26
まぁ糞言語である事は揺ぎ無いよね
すでに投資しすぎたとか諸々の事情で選択肢からはずっと外れないんだけどさ
0128デフォルトの名無しさん2008/09/21(日) 00:10:43
糞言語ではないだろう
テンプレートなんか後発言語は皆ジェネリックで真似してるし
0129デフォルトの名無しさん2008/09/21(日) 00:24:24
どう糞なのかを説明して欲しい
0130デフォルトの名無しさん2008/09/21(日) 00:24:44
>>128
部分的に良いところもある壮大な実験言語だったかもね
ただし、どう考えても言語としては糞だと思う
0131デフォルトの名無しさん2008/09/21(日) 00:59:49
その糞を説明しないと
0132デフォルトの名無しさん2008/09/21(日) 01:01:23
説明できないんだろ
とにかく　糞　と言いたいだけの厨だよ
0133デフォルトの名無しさん2008/09/21(日) 01:07:02
>>132
・肥大化した仕様
・C言語との互換性がなくなってしまった
・静的なオブジェクト指向
・マルチパラダイムを言い訳にしているが、いくらでも醜いコードをかけてしまう
0134デフォルトの名無しさん2008/09/21(日) 01:12:09
欠点ばっかり挙げてもな
利点も挙げてみろ

なぜ世の中のプログラムの多くがC++で書かれているのか
その理由がわからないのか
0135デフォルトの名無しさん2008/09/21(日) 01:16:54
C++を糞だと言うひとは
あるコンポーネントを実装する言語を選ぶ際に様々な言語を多角的に評価した結果
CとC++が残ったというシチュエーションならどっちを選ぶの？
0136デフォルトの名無しさん2008/09/21(日) 01:19:05
>>134
>133を裏返したら利点になる
0137デフォルトの名無しさん2008/09/21(日) 01:20:52
という事は>>133は単にC++をけなしたいだけの香具師か
0138デフォルトの名無しさん2008/09/21(日) 01:34:36
>>135
そこでObjective-Cですよ
0139デフォルトの名無しさん2008/09/21(日) 01:39:53
VC以外日陰だろ
0140デフォルトの名無しさん2008/09/21(日) 01:55:47
Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ
C++とは守備範囲が違うと思う

っていうかあんなとってつけたような違和感バリバリの言語を薦めておいて
C++を糞だと言ってんのか
0141デフォルトの名無しさん2008/09/21(日) 01:56:14
組み込み系ではCが主流だしｗ
0142デフォルトの名無しさん2008/09/21(日) 02:12:51
>>141
コンパイラが少ないからじゃない？
0143デフォルトの名無しさん2008/09/21(日) 02:56:05
過剰なC++擁護派はやっぱ馬鹿だなｗ
C++以外の選択肢が無い状況なんていくらでもあるが、糞言語と言う事実にはなんら影響しない。
Windowsみたいなもんだと言えば理解できるか？
0144デフォルトの名無しさん2008/09/21(日) 03:41:16
無い頭使って必死に習得した学習コストを考えると盲目にマンセーするしかないんだろ
0145デフォルトの名無しさん2008/09/21(日) 08:28:02
C++/CLIを介さずにC++のネイティブコードを透過的に
C#から使うことができれば、まだ使い道はあると思うけど
0146デフォルトの名無しさん2008/09/21(日) 08:56:47
C++ではソースコードが肥大化しすぎる
言語仕様が弱すぎて、動的エラーを起こす一目でバグと分かるコードでもコンパイラが余裕で通す
C++でGUI作ってるのとか見るとC#やjavaを使った方が100倍速く短く作れる事実を知らんのだろうなあと思う
0147デフォルトの名無しさん2008/09/21(日) 09:35:20
それで10倍実行速度が遅いと。
0148デフォルトの名無しさん2008/09/21(日) 09:39:14
C/C++の弱点って、作られたバイナリの対象となる実行環境が限られるって事だけじゃん
それ以外の弱点っていうのは、ちょっと思いつかないなぁ
0149デフォルトの名無しさん2008/09/21(日) 10:13:34
C#とかJavaでロジックを組んでるのとか見るとHaskellやprologを使った方が100倍短かく早く作れる事実を知らんのだろうなあと思う
0150デフォルトの名無しさん2008/09/21(日) 10:23:12
でもHaskellやPrologで作ったOSは知らないなあ
0151デフォルトの名無しさん2008/09/21(日) 10:32:27
Cのプログラマーが溢れて給料低下だから、
わざとごちゃごちゃしたC++作ったってネタは面白かったｗ

まぁ、俺はカプセル化だけでもC++の意味はあると思うが。
そもそもプログラムなんて使えるライブラリがあるかどうかで90%は決まる。
0152デフォルトの名無しさん2008/09/21(日) 11:13:29
>>140
>Objective-CはCを超える表現力を望んだとたんにインタプリタレベルの効率になるんでしょ

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

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

組込みとかには向いていないかもね
でもiPhoneだと問題なく動いているし、組込みも高度化するとObjective-Cが使えるってことかと
0153デフォルトの名無しさん2008/09/21(日) 11:22:20
C++でも仮想関数使えばObjective-Cと同じになるのではないかと
0154デフォルトの名無しさん2008/09/21(日) 12:56:21
>>147
100nsが1msになったところでGUIアプリにとっては大部分がどうでもいいんです
何言ってるか分かりますか？

ホットスポットだけDLLで外出しすれば100倍早く作れて体感できない程度しか遅くならないんです
何言ってるか分かりますか？
0155デフォルトの名無しさん2008/09/21(日) 13:29:27
>>153
配列のインデックスアクセスとハッシュの要素アクセスの違いがあるんじゃないの
0156デフォルトの名無しさん2008/09/21(日) 13:31:40
>>154
それが問題なんだよ。
プログラムは ８：２ の法則があるのを知ってるだろ。

要するにプログラムの実行時間の大半は２割のコードが
費やしているという事だが、その部分の速度が１／１０に
なったらもっさりするだろ。
0157デフォルトの名無しさん2008/09/21(日) 13:33:09
言葉だけ書いてもアレなんで実アプリで説明してみると、
例えばLimeWireってあるだろ。あれはJavaアプリだが、
実に動作がもっさりしている。

WinnyやShareと比べものにならない位もっさりしている。
0158デフォルトの名無しさん2008/09/21(日) 13:34:56
>>156
何言ってるのか全く分からなかったんですね
残念です
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人で乗っかったら
そのテーブルの台が割れちまった。
痛いと思ったらなんか石と鉄の棒みたいなので
足挟まってた。石をどけると
何か大きな箱の中に入ったみたいで中には
キラキラ光る数珠の玉みたいのとか、鉄の棒、汚れた布切れ
と小さい円盤みたいなものが何枚かあったよ。
俺は面白えと思ってみんなに内諸にしようと約束
して外にでることにした。
俺たちが外に出ようとして元の出口の方にいったら
ゴゴゴゴーとか地鳴りが聞こえて水が突然津波みたいに
俺たちを流した。
その後俺たちは田んぼまで流れてその場所が
どこかわからなくなっちまった。
後で大きくなった時にそこの場所が改めて確認した。
崩れたまま今は草ボーボーになって残ってる。
0259デフォルトの名無しさん2008/09/28(日) 20:18:20
MPI使った分散計算とかに使うととたんに困る。
ポリモフィックなことしてたりすると、型情報をつけておくって、
受けた方は型情報に従ってseitch caseなどで羅列した生成ルーチンを選択して・・・てなことになる。
新しい派生型を加える度にcaseを追加しないといけない。
自動的に派生クラスのコンストラクタを実行とかできないからね。

これはなにもプロセス間通信じゃなくても、クラスオブジェクトのデータをいったんファイルにセーブして再度読み込むとかでも同じ問題が起こる。
0260デフォルトの名無しさん2008/09/28(日) 21:45:15
だからCで同じことやろうとしても同じ問題が起こるっつーの。
オブジェクトをそのままファイルに保存とかアホかと。
あと型情報でswitchとかやるのは単なる設計ミスか、あるいはテンプレートで回避できる。
自分の不勉強を棚に上げて、口数少なく記述できないことを言語のせいにすんな。
0261デフォルトの名無しさん2008/09/28(日) 22:17:27
switch caseを無くせるのがC++の面白いところなんだけどね
0262デフォルトの名無しさん2008/09/28(日) 22:32:19
どんな言語でもそりゃswitchの羅列になる。
よその言語だとそうならないようにシリアライズって機構があるだろ。
C++だってBoostとかが作ってはいる。望みどおりのものかどうかは別として。
0263デフォルトの名無しさん2008/09/28(日) 23:14:40
仮想関数使ってできるだけswitchとかif elseをなくすのが
C++の方向じゃないのか
禿もそう言ってたろ
0264デフォルトの名無しさん2008/09/29(月) 00:04:27
でも最終的には、マシン語でifになるからＥじゃんＥじゃんＥＥjump
0265デフォルトの名無しさん2008/09/29(月) 00:19:54
x86で大抵のコンパイラは call [eax+table] みたいなコードになるぞ
0266デフォルトの名無しさん2008/09/29(月) 13:01:01
仮想関数によるswitch排除は美しいと思うけど
現実的には、あとからの機能追加とかで
ちょっとした分岐が入る場合にｇｄｇｄになりがち
0267デフォルトの名無しさん2008/09/29(月) 20:23:11
仮想関数をしっかり使うには、結構設計に悩むが、うまくはまるとかなりいいぞ
0268デフォルトの名無しさん2008/09/29(月) 21:27:47
オブジェクト指向やデザインパターンのおかげで変更に強く大きなアプリケーションも
作りやすくなったんだよ。GoF のデザインパターンはほとんど仮想関数使ってるよ。
0269デフォルトの名無しさん2008/09/29(月) 21:34:01
仮想関数である必要はないよ
テンプレートメソッドやステートやストラテジーパターンなんてジェネリックスでもできる
他は忘れちゃった
0270デフォルトの名無しさん2008/09/29(月) 21:39:05
都銀レベルの本当に巨大なシステムは皆COBOLだけどな
0271デフォルトの名無しさん2008/09/29(月) 22:12:43
でも、COBOL開発には夢がない。楽しくもない。
0272デフォルトの名無しさん2008/09/29(月) 22:13:51
そう言えば禿はC++の設計時に「楽しくプログラミングできる事を目指す」
ような事を言っていたな
0273デフォルトの名無しさん2008/09/29(月) 22:15:06
その割りに出来上がったのがこれかよ
0274デフォルトの名無しさん2008/09/29(月) 22:35:51
プログラマーから拡張につぐ拡張の要求が押し寄せて
C++標準化委員会が断り続けたが押し切られたものもあって
カオスになっている
0275デフォルトの名無しさん2008/09/29(月) 22:44:49
それもまた一興
0276デフォルトの名無しさん2008/09/29(月) 22:48:08
一つの言語で何でもやろうとするからこうなる
MultixやPL/Iと同じだな
0277デフォルトの名無しさん2008/09/29(月) 22:56:06
まーMFCみたいに我が道路線で行けばそれなりに安定してる言語だけどね
0278デフォルトの名無しさん2008/09/29(月) 23:02:55
今日、インストーラのカスタム動作というのをC#で実装してて
初めてドットネットのライブラリを使った
何だあれは！
ほとんど同じ機能を持つ違う名前のクラスが山ほどあるじゃないか
InstallerCollection って何？ただの配列じゃない
InstallContext って何？辞書を一つ持ってるだけじゃない。つまりただの辞書じゃない

あんなのを使う機会が増えていくのは嫌だな
スレと関係なくなっちゃってスマンな
0279デフォルトの名無しさん2008/09/29(月) 23:32:41
>>274
それってどの機能のこと？
0280デフォルトの名無しさん2008/09/29(月) 23:48:18
演算子のオーバーロード
0281デフォルトの名無しさん2008/09/30(火) 00:16:28
>>277
STLより古いしね
0282デフォルトの名無しさん2008/09/30(火) 01:31:13
>>281
演算子のオーバーロードって本当は入れたくなかったんだ。
初めて知った。
0283デフォルトの名無しさん2008/09/30(火) 03:41:08
>>282
あんな糞気持ち悪いもんマトモな神経持ってたら拒否る
0284デフォルトの名無しさん2008/09/30(火) 03:44:02
タイプ量が劇的に減っていいじゃん
0285デフォルトの名無しさん2008/09/30(火) 03:57:12
お前のタイプ量が減った分周りの人間が苦労してるだけなんだけど
まぁ、お前はいいんだよね、お前はさ
0286デフォルトの名無しさん2008/09/30(火) 03:59:16
D&E読んでみたけど、演算子オーバーロードについては
Dr.Bjarne自身は入れたくなかったわけではないらしいよ。
実装の難しさ（勿論コンパイラの。）やユーザにとっての難解さがあるんじゃないかと
ためらってたが検証したらそうでもなかったので取り入れたと言ってる。
「どんな言語を使ってもわかりにくいコードを書く人はいる。
誤用を恐れるよりは、便利さに目を向けた方がいい」とのこと。

実際、行列とかのクラスで mat1.Multiply(mat2.Multiply(mat3))とかイヤすぎる・・・
0287デフォルトの名無しさん2008/09/30(火) 04:00:48
>>285
それはお前の職場環境が悪いだけ。
バカがバカなコード書くのを言語のせいにするなと。
0288デフォルトの名無しさん2008/09/30(火) 05:13:46
　　 _,,....,,_　 ＿人人人人人人人人人人人人人人人人人＿
-''":::::::::::::｀''＞便利さに目を向けた結果が今のC++だよ！！　＜
ヽ:::::::::::::::::::::￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^^Ｙ^ＹＹ^Ｙ^Ｙ^Ｙ^Ｙ^￣
　|::::::;ノ´￣＼:::::::::::＼_,. -‐ｧ　　　　　＿_　　 _____　　 ＿_____
　|::::ﾉ　　　ヽ､ヽr-r'"´　　（.__　　　　,´　_,, '-´￣￣｀-ゝ 、_ イ、
_,.!イ_　　_,.ﾍｰｧ'二ﾊ二ヽ､へ,_7　　　'r ´　　　　　　　　　　ヽ、ﾝ、
::::::rｰ''7ｺ-‐'"´　 　 ;　 ',　｀ヽ/｀7　,'＝=─-　　　 　 -─=＝',　i
r-'ｧ'"´/　 /!　ﾊ 　ハ　 !　　iヾ_ﾉ　i　ｲ　iゝ、ｲ人レ／_ルヽｲ i　|
!イ´ ,' |　/__,.!/　V　､!__ﾊ　 ,'　,ゝ　ﾚﾘｲi (ﾋ_] 　　 　ﾋ_ﾝ ).| .|、i .||
`! 　!/ﾚi'　(ﾋ_] 　　 　ﾋ_ﾝ ﾚ'i　ﾉ　　　!Y!""　 ,＿__, 　 "" 「 !ﾉ i　|
,'　 ﾉ 　 !'"　 　 ,＿__,　 "' i .ﾚ'　　　　L.',.　 　ヽ _ﾝ　　　　L」 ﾉ| .|
　（　　,ﾊ　　　　ヽ _ﾝ　 　人! 　　　　 | ||ヽ、　　　　　　 ,ｲ| ||ｲ| /
,.ﾍ,）､　　）＞,､ _____,　,.イ　 ハ　　　　レ ル｀ ー--─ ´ルﾚ　ﾚ´
0289デフォルトの名無しさん2008/09/30(火) 05:20:30
演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
0290デフォルトの名無しさん2008/09/30(火) 05:37:01
なんでそんな入社一年目でも普通に使ってる初歩的機能に熱く議論してんだ？
新入社員がlambdaとmplでばかり書いてしまって困ってますとかなら議論できそうだが。
0291デフォルトの名無しさん2008/09/30(火) 05:41:07
なんでC++擁護派っぽいカキコってこんなヌケてるの？
アンチの工作なの？
0292デフォルトの名無しさん2008/09/30(火) 09:22:59
C++擁護派って新人もしくは学生でWindows好きそうなイメージがある
0293デフォルトの名無しさん2008/09/30(火) 10:54:01
>>289
×演算子オーバーロードってバカが俺ってSUGEEEEEEするための機能だろ
○C++ってバカが俺ってSUGEEEEEEするための言語だろ
0294デフォルトの名無しさん2008/09/30(火) 11:00:24
G++ごときで挫折したマヌケですね
0295デフォルトの名無しさん2008/09/30(火) 12:25:54
演算子オーバーロードは単なる表記の便利さの問題じゃなくて
ダックタイピングの言語では必然と言っていいと思うがな

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

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

C++もテンプレートの世界は一種の静的ダックタイピングだから
演算子オーバーロードは本質的で、それなしでは
組み込み配列やポインタ、関数を
全く同じように扱えるSTLのようなライブラリは作れないし
生まれなかったよ
0296デフォルトの名無しさん2008/09/30(火) 12:57:24
文字列の連結が＋なのはとても整数のようでは
0297デフォルトの名無しさん2008/09/30(火) 13:16:32
文字列の + による結合は自然じゃないか？
演算子オーバーロードのない Java ですら文字列は特別に + を使えるようにしている。
0298デフォルトの名無しさん2008/09/30(火) 13:16:44
operatorが難しいとか感じる奴は死んでいいでしょ
0299デフォルトの名無しさん2008/09/30(火) 13:53:01
>>298
>operatorが難しいとか感じる奴
誰もそんな話してないんだけど
唐突にどうした？
0300デフォルトの名無しさん2008/09/30(火) 13:59:14
>>289あたりのことを指してるんだろうが
演算子オーバーロード否定論者ってJava厨あたりじゃないの
今時C#やPythonやRubyにもあるような機能なんだけど
となりのブドウはすっぱいという奴だろう
0301デフォルトの名無しさん2008/09/30(火) 14:33:03
+は普通可換だけど、文字列の連結は可換じゃないよね。
0302デフォルトの名無しさん2008/09/30(火) 14:43:12
文字列に+はある意味趣味の問題だろうな

BigNumや複素数、クォータニオン、ベクトル、行列のようなものに
演算子オーバーロードが使えるかどうかはかなり大きな問題だが
0303デフォルトの名無しさん2008/09/30(火) 15:56:59
演算子オーバーロードは複素数計算では必須。だから、C++とC#しかない。
0304デフォルトの名無しさん2008/09/30(火) 17:11:28
Fortranにもある
0305デフォルトの名無しさん2008/09/30(火) 18:20:14
DにもDelphiにもある。
0306デフォルトの名無しさん2008/09/30(火) 21:29:08
参照とポインタ、両方ともC++に実装せずに片方だけ実装すれば、よかったかも、

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

例外処理も削れない。

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

あんま削るとこ無いね。
0307デフォルトの名無しさん2008/09/30(火) 21:48:07
STLを自作してたら、他人のライブラリと組み合わせるとき悲惨だぜ
自分の作った車輪と他人が作った車輪が乱立しているなんて耐えられない
0308デフォルトの名無しさん2008/09/30(火) 21:54:36
>>306
参照とポインタはclassとstructぐらい違うぞ
0309デフォルトの名無しさん2008/09/30(火) 21:54:47
>>306
ターゲット環境が貧弱で、constやカスタムアロケータや配置newを使いまくる人？
そういう人は例外も使わなそうな印象があるが
0310デフォルトの名無しさん2008/09/30(火) 21:55:26
>>308
> classとstructぐらい
それって大した違いじゃないなｗ
0311デフォルトの名無しさん2008/09/30(火) 21:59:00
>>306
>STLは微妙、自分で作った方が使いやすい（気分がする）
これは狂気の沙汰と言わざるを得ない
0312デフォルトの名無しさん2008/09/30(火) 22:00:21
参照に関してはコンパイラ側で
ポインタを用いた内部実装しろと強制されているわけではないが
実質ほとんどのコンパイラは同じにしているだろう

せいぜい関数のインライン展開の場合に変わるぐらいか？
0313デフォルトの名無しさん2008/09/30(火) 22:06:37
>>306
アンチC++工作員乙ｗ
0314デフォルトの名無しさん2008/09/30(火) 22:17:04
stlは結局必要なものがない
あと基本設計がクソ過ぎる
0315デフォルトの名無しさん2008/09/30(火) 22:31:02
とうぞ糞でないものを教えてください
0316デフォルトの名無しさん2008/09/30(火) 22:32:42
とうぞ糞？
0317デフォルトの名無しさん2008/10/01(水) 01:30:27
>>314 「ただ１つのベースクラスから継承して作っていないとか、どんだけクソ設計なんですか＾＾」
とかだったら笑う。
0318デフォルトの名無しさん2008/10/01(水) 01:38:06
>>317
そんな発想できるお前に笑った
0319デフォルトの名無しさん2008/10/01(水) 01:45:42
かゆいとこに手が届かない感じだよ。CStringからstringとかにわざわざダウングレード
するのもどうかと思う。
0320デフォルトの名無しさん2008/10/01(水) 01:51:00
CStringのどのあたりが優れてる？
0321デフォルトの名無しさん2008/10/01(水) 03:55:39
STLといえば、まずは vector, list, mapじゃないの？
string系はおまけ的なものだから論点が違うよ
0322デフォルトの名無しさん2008/10/01(水) 04:03:48
そもそも環境依存のアプリ屋は、C++を積極的に使う必要はないだろ
C#やobject Cと、最新ライブラリをを使う方が効率がいいじゃないか

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

ここには、言語の乱立を嫌がる人もいるが違うと思うな モノには適材適所がある
0323デフォルトの名無しさん2008/10/01(水) 05:25:46
vectorはメモリの連続性が信用できないから素直に配列の方がいい
listもリンクリスト程度なら自分で作った方が安心できる
mapは便利だけどクソ遅い

STLは富豪プログラミングできるときにだけ使えて
mapとsetだけが多少とも役に立つ
0324デフォルトの名無しさん2008/10/01(水) 05:41:09
メモリが連続している必要があるの？
まあ、連続していないとアクセスは遅くなるけどさ。
気にするほどのものかな
0325デフォルトの名無しさん2008/10/01(水) 06:03:04
連続してないならないで別にいい（それがdequeだしな）
信用できないというのが大問題
0326デフォルトの名無しさん2008/10/01(水) 07:57:47
vectorで確保するメモリは連続だったでしょ
stringと勘違いしてない?
0327デフォルトの名無しさん2008/10/01(水) 08:06:31
http://www.cranehouse.jp/program/vector.html
こんなの発見。
昔のコンパイラだと連続していなくとも標準を名乗れたらしい。
0328デフォルトの名無しさん2008/10/01(水) 09:24:58
std::vector 連続 で検索すれば答えは出てくる
当初の規格書に明言されてなかったのは問題だったけど
0329デフォルトの名無しさん2008/10/01(水) 10:05:05
言語が効率第一なわりに何でもコピーベースだよな
CVOつっても限界あるし
参照ベース + GCな言語より非効率な面もかなり多いんじゃないか

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

STLは、C++標準ライブラリの中では一番マシじゃないのか
iostreamだのlocaleだのはどうしようもない
03303292008/10/01(水) 10:31:04
なんだCVOってｗ
RVOだ、すまん
0331デフォルトの名無しさん2008/10/01(水) 10:37:52
カスタム・ヴィークル・オペレーション
0332デフォルトの名無しさん2008/10/01(水) 10:48:31
>>322
広いレンジって言っても文字が文字コード想定してないってだめでしょ。
JavaもC#もStringとかStreamはちゃんと変換できるようになってるからみんな
おとなしく使ってるでしょ。
0333デフォルトの名無しさん2008/10/01(水) 11:39:18
文字コード変換ってでっかいテーブルが必要だったりするから
組み込みでは難しかったりするんだろう
ライブラリに任せるというのは比較的真っ当なやり方だと思うがね

そもそもC/C++標準ではファイルシステムの存在すら仮定してないし
そういったシステムに依存するような仕様を緩くして
実装可能な範囲を広げようというスタンスなんだろう
0334デフォルトの名無しさん2008/10/01(水) 11:47:29
標準にlocaleがあるしcodecvtファセットがエンコード変換することになってるよ

まあ糞だけど
0335デフォルトの名無しさん2008/10/01(水) 17:39:52
間違った所を緩めてどうでもいい所を締めるから
COAP（笑）だのvector<bool>（爆）だのみたいな悲劇が生まれるんだよ
0336デフォルトの名無しさん2008/10/01(水) 17:46:37
どう考えてもMFCやVCLが実用的
0337デフォルトの名無しさん2008/10/01(水) 17:50:15
>> 336
組み込みでMFCやVCLは動きません 役割が違うのに批判されても困るわ
0338デフォルトの名無しさん2008/10/01(水) 17:50:47
何度ループしても糞であるという結論にしか至らないC++(笑)
0339デフォルトの名無しさん2008/10/01(水) 17:57:34
アホですね（笑）
0340デフォルトの名無しさん2008/10/01(水) 17:58:35
組み込みでSTLなんてそれこそ使えるか
0341デフォルトの名無しさん2008/10/01(水) 17:59:14
言語の標準ライブラリが特殊環境を想定する必要はない
0342デフォルトの名無しさん2008/10/01(水) 18:00:08
いまどきの組み込みはJavaや.NETが普通に動く世界なんだろ
0343デフォルトの名無しさん2008/10/01(水) 18:01:08
そんなのはハイエンドか産業用だけです
0344デフォルトの名無しさん2008/10/01(水) 18:08:44
Lispで動く炊飯器を見たい
0345デフォルトの名無しさん2008/10/01(水) 18:12:53
STLは、単品で使うには粗末だし。
メーカーのライブラリの基盤に採用するには癖が強すぎる。
何より標準ライブラリを名乗っている割に後発なのが痛い。
0346デフォルトの名無しさん2008/10/01(水) 18:14:44
もはや組み込み専用マイナー言語に落ち果てているのに
仕様的には肥大化しきってる

ぶっちゃけCでいいじゃん
人生をかけてC++を学んだ様な奴は認められないんだろうけど(笑)
0347デフォルトの名無しさん2008/10/01(水) 18:17:22
>>346
主な需要は組み込み、ゲーム、パッケージソフト
てなとこか
でも組み込みはどっちかっつうとCのがまだメインなんじゃないか？
他ではほとんど死んでるな

パッケージも、本当はC++である必要が無い気がするな
.NETやJavaまでいかんでも、リッチなOSを前提にできるんなら
GCぐらいはあってもいいし、ギチギチのzero overhead ruleなんて必要ない
0348デフォルトの名無しさん2008/10/01(水) 18:30:51
結論としては、CとC++の中間くらいが一番良さそうだな。
つまり、基本Cみたいな使い方でゴテゴテしたC++の機能は使わなかった俺が正解か。
0349デフォルトの名無しさん2008/10/01(水) 18:35:08
C++の素晴らしいところは本物のデストラクタを持ってることだ
リソースの完全な管理という点では今でも右に出る言語はないと思っている
0350デフォルトの名無しさん2008/10/01(水) 18:38:23
>>349
そっすねｗ
自己管理がんばってくださいｗｗ
0351デフォルトの名無しさん2008/10/01(水) 18:42:36
うんｗ
実際自己管理を頑張らなきゃならない場合ってのはあって
そういう時だけはC++は本当に役に立つし、なくてはならないんだよ
そういう時だけはな
0352デフォルトの名無しさん2008/10/01(水) 18:50:23
Pythonみたいに参照カウントとマーク＆スイープ併用してる言語もあるよ

C++でshared_ptr使って参照カウントは出来るが、フツーのGCより効率悪いよね
便利機能一切使わない覚悟でないとC++のコードは速くならないっつか
確実にCより遅くなる
スレッドのことは勿論なにも考えてないからマルチコア時代では先が見えてるしな
0353デフォルトの名無しさん2008/10/01(水) 18:51:00
デストラクタならJAVAのほうがマシな実装だと思うぞ
0354デフォルトの名無しさん2008/10/01(水) 18:54:28
>>353
廃棄のタイミングを厳密に制御したいんでしょ

Pythonはブロック抜けで参照カウント0になれば廃棄されるし
（当たり前だがデストラクタは定義できるし実行される）
巡回参照でも大丈夫だよ
0355デフォルトの名無しさん2008/10/01(水) 18:56:04
>>348
D言語ですね、

でも、現在迷走中。
0356デフォルトの名無しさん2008/10/01(水) 18:57:16
Dは最初の狙いは悪くなかったと思うけど
開発者の独りよがりな趣味で終わりそうだね
0357デフォルトの名無しさん2008/10/01(水) 19:01:03
>>353
Javaのはデストラクタじゃなくてファイナライザ
ファイナライザは全然役に立たない
0358デフォルトの名無しさん2008/10/01(水) 19:07:32
C++/CLI最強説
0359デフォルトの名無しさん2008/10/01(水) 19:24:17
>>358
割と本気でそう思ってるんだが誰も同意してくれない
0360デフォルトの名無しさん2008/10/01(水) 19:39:17
>>358
C#の方が好きだ。
0361デフォルトの名無しさん2008/10/01(水) 19:45:55
C#もデストラクタないんだよな…
0362デフォルトの名無しさん2008/10/01(水) 19:47:53
IDisposable
0363デフォルトの名無しさん2008/10/01(水) 19:50:47
それデストラクタじゃなくてdelete
0364デフォルトの名無しさん2008/10/01(水) 19:52:01
using(Hoge hoge = new Hoge())
{
　//なになに
}
0365デフォルトの名無しさん2008/10/01(水) 19:53:40
確かにマルチスレッドとかマルチプロセスに特化した言語は欲しいな。
0366デフォルトの名無しさん2008/10/01(水) 19:54:54
うお、そんな書き方出来るのか初めて知った

C#いいな！
0367デフォルトの名無しさん2008/10/01(水) 19:58:04
でもC#にはローカル変数とかのfinal宣言子がない…
あればいいのに　あれば…
0368デフォルトの名無しさん2008/10/01(水) 19:59:38
>>364
同じキーワードをあっちこっちの用途で流用するところはC++譲りみたいだな
0369デフォルトの名無しさん2008/10/01(水) 20:00:52
>>364
それ使いたいオブジェクトの数が増えると構文が悲惨よw
0370デフォルトの名無しさん2008/10/01(水) 20:01:01
もしかしてJavaもできるの？
C++はdeleteし忘れるからGC最高とか言ってる奴らが
結局finally節にdispose()とかclose()とかunlock()とかチマチマ書いてるのが
とっても滑稽だと思って以来いい印象ないんだけど
出来るなら認識改めないと
0371デフォルトの名無しさん2008/10/01(水) 20:05:30
スマポでええヤン
0372デフォルトの名無しさん2008/10/01(水) 20:08:51
コンテナに入らないふざけた奴か
0373デフォルトの名無しさん2008/10/01(水) 20:10:56
スマポが悪いんじゃないんです
auto_ptrがアホの子なだけなんです
COAPとか使いたがる奴らが悪いんです
許してあげて下さい
0374デフォルトの名無しさん2008/10/01(水) 20:17:30
まさに 「痒い所に手が届かない」
0375デフォルトの名無しさん2008/10/01(水) 20:18:10
tr1まで標準にリファレンスカウントなスマポ入れなかったってのは、
そもそも標準にスレッドセーフという概念が無いからか？
どっちみちSTLがスレッド？何それ？状態だから関係ねーけどな

ヨボヨボすぎて、もうモダンなOSの主要言語の座はとっくに引退していい仕様だろ
お爺ちゃんをいつまでも無理して使いすぎなんだよ
0376デフォルトの名無しさん2008/10/01(水) 20:21:27
0xでようやくスレッドの概念が入って
スレッドローカル変数とかが定義できるようになるらしいけどな

マトモになるのはいつになるやら
0377デフォルトの名無しさん2008/10/01(水) 20:26:31
iostreamとか、仕様練る時に変だろこれと誰一人思わなかったのかな。
0378デフォルトの名無しさん2008/10/01(水) 20:26:44
え？マトモにする予定なんてあるの？
0379デフォルトの名無しさん2008/10/01(水) 20:31:52
>>377
sprintfひとつですむことを
だらだら << 繰り返して書くのが楽しい。┐(´∇｀)┌
0380デフォルトの名無しさん2008/10/01(水) 20:33:38
>>370
GCが便利なのはいっちいっちコピー先バッファとか
頭の悪いもの引数に用意しなくて済むからだよ。
0381デフォルトの名無しさん2008/10/01(水) 20:40:32
shared_ptrとか使って、ただのポインタアクセスをいちいち高価なものに
置き換えたりする必要も無いしな
0382デフォルトの名無しさん2008/10/01(水) 20:44:10
GCはshared_ptrなんぞよりよっぽど高価ですが
0383デフォルトの名無しさん2008/10/01(水) 20:49:05
>>377
iostreamの凄いところは、初期の仕様を捨ててわざわざ新しくしたのにそれでも糞であるというとこだね。
iostream絡みの昔のコードはどのみち通らないんだから、それなら思い切って捨ててしまえば良かったのに。
0384デフォルトの名無しさん2008/10/01(水) 20:54:12
マネージだからメモリリークしないと思っている人。
確かに、プログラムが終了するときにはリークしないでしょう。
けれど例えば、ある操作を繰り返すたびにメモリが解放されずに残ってしまう
ということは有り得ます。Javaでも同様です。
たとえば、ArrayListにStringを追加し続けているようなものです。
0385デフォルトの名無しさん2008/10/01(水) 21:01:53
GCは普通に使う分には便利だが
ゲームのオブジェクト管理とかやろうと思うとウザくなる
0386デフォルトの名無しさん2008/10/01(水) 21:02:09
>>384
unmanagedでもプログラム終了したらリークはしないでしょう。
何か特別なことしない限り。
0387デフォルトの名無しさん2008/10/01(水) 21:07:02
>>358
C++/CLIもコレクションに入れるとデストラクタが無力化する
0388デフォルトの名無しさん2008/10/01(水) 21:08:36
まあ、そんなに参照されるのがいやならソフトリファレンスでも使えや
0389デフォルトの名無しさん2008/10/01(水) 21:50:39
>>387
msclr::auto_handleは？
0390デフォルトの名無しさん2008/10/01(水) 21:53:43
そもそもauto_handle自身のデストラクタが働かないから㍉
0391デフォルトの名無しさん2008/10/01(水) 22:35:54
やっぱりmallocが最高だな。
0392デフォルトの名無しさん2008/10/01(水) 23:54:57
aro
0393デフォルトの名無しさん2008/10/02(木) 00:39:29
C++0x みたいな継ぎ接ぎはもういいから、新しいプログラミング言語の作成しろ。
0394デフォルトの名無しさん2008/10/02(木) 01:43:49
STL を組み込みで使えないという意見があったが、
処理系のデフォルトの operator new とか std::allocator
とかを使わないというだけで、<algorithm> も使うし
自前アロケータでコンテナも使うよ。
0395デフォルトの名無しさん2008/10/02(木) 09:16:30
C言語を完全に駆逐するためには
http://pc11.2ch.net/test/read.cgi/tech/1210158702/
0396デフォルトの名無しさん2008/10/02(木) 10:58:03
unixの設計のためにCを作ったように、
新しいOSのために、全く新しい言語が生み出されるであろう。
0397デフォルトの名無しさん2008/10/02(木) 11:29:35
んなこたぁー、ない。
0398デフォルトの名無しさん2008/10/02(木) 18:09:47
Be…
0399デフォルトの名無しさん2008/10/02(木) 18:30:28
並列プログラミングが重要視される時代なのでやっぱり新しい言語が必要。
0400デフォルトの名無しさん2008/10/02(木) 18:33:23
ConcurrentC
0401デフォルトの名無しさん2008/10/02(木) 18:41:36
Nextだろ
0402デフォルトの名無しさん2008/10/02(木) 23:07:59
素朴な疑問なんだが
C++がCより開発効率が良いって主張あるよな？
ひとによっては暗黙の了解になってるぽいんだが
それって誰がいつどうやって比べたの？
ソースはあるの？
0403デフォルトの名無しさん2008/10/02(木) 23:32:14
鉛筆を一本ずつ数えるのとダースで数える程度の違い
ヘッダファイルの仕様化度が高いともいえるけど
所詮はマクロアセンブラを構文化しただけの言語
いくらでも非効率にも効率的にもできる
0404デフォルトの名無しさん2008/10/02(木) 23:34:08
↑に付いては知らんけど、COBOLの方がJavaよりも開発効率がいいなんて言い出すCOBOL脳には成るなよ。
04054042008/10/02(木) 23:36:10
>>402
0406デフォルトの名無しさん2008/10/02(木) 23:40:42
>>402
高級言語の中で比較するんならどっちみちC++の生産性は低い
それ以上に再利用のしにくさが致命的
ABIが糞でコンパイル時計算への依存度が高いからな
0407デフォルトの名無しさん2008/10/02(木) 23:41:06
一応COBOLは開発効率を重視した言語だ
ただし、プログラマー向けじゃないけどね
0408デフォルトの名無しさん2008/10/02(木) 23:46:15
ソースは？脳内？
0409デフォルトの名無しさん2008/10/03(金) 00:01:41
個人的には、高級言語の皮を被った低級言語って感じでいいんだけどな。
基本Ｃでいいんだけど、少しだけ楽したいみたいな。
0410デフォルトの名無しさん2008/10/03(金) 00:12:25
ソースもなにも両方でプログラム作れば感覚でわかるだろ。
0411デフォルトの名無しさん2008/10/03(金) 01:42:23
CがC++よりいいって・・どうやってWindow表示すんの？MFCとかATLとか使わんの？クラスも使わんの？
CreateWindow(........)とかばっかしてがんばるの？なんなの？ばかなの？
0412デフォルトの名無しさん2008/10/03(金) 01:50:29
いい加減、開発の目的や背景を理解できるようになってくれ
0413デフォルトの名無しさん2008/10/03(金) 02:06:05
>>411
酷い馬鹿を見た
>>1から1000回読み直せ
0414デフォルトの名無しさん2008/10/03(金) 02:17:32
適切な設計をすればCよりは保守性も効率も上がると思うんだけど。
なんか極端なアンチが沸いてるが（俺ももちろんC++が楽だとは言わんが）、
必死に叩いてる奴って、クラスやテンプレートの使い方のセンスが無いor
理解できてない馬鹿ばっかりじゃないの？
単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
機能の使い方が悪い以外に考えられん。
0415デフォルトの名無しさん2008/10/03(金) 02:28:59
> 単純に考えてC++はCに機能が増えただけなんだからCより悪くなるのは
> 機能の使い方が悪い以外に考えられん。

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

C++みたいな半端な言語で何でもやろうとするのではなく、もっと高級で
ずっと生産性の高い言語とCを組み合わせるという選択も普通にあるんだが、
それも見えていないようだね
0416デフォルトの名無しさん2008/10/03(金) 02:39:29
まぁ、実際を考えると、マルチプラットフォームで使えるちゃんとしたコンパイラがあるかどうかってのもあるなｗ
0417デフォルトの名無しさん2008/10/03(金) 02:49:20
>>414
なるほど、C++の標準の策定者は「理解できてない馬鹿」で「機能の使い方が悪い」
からiostreamとか作っちゃうわけだな
0418デフォルトの名無しさん2008/10/03(金) 02:59:05
実用性は無くても、オブジェクト指向言語の可能性を立派にアピールしたよ
0419デフォルトの名無しさん2008/10/03(金) 03:01:58
C++をOOの代表であるかのごとくに言ったらOO信者の猛反発喰らうぞｗ
0420デフォルトの名無しさん2008/10/03(金) 03:14:54
C++はOOのOOらしさを極限までそぎ落とし、効率に振り向けた言語だからな
0421デフォルトの名無しさん2008/10/03(金) 03:55:47
オブジェクト指向言語の可能性←大間違い
オブジェクト指向の可能性←ギリギリおｋ
0422デフォルトの名無しさん2008/10/03(金) 04:01:16
SimulaとSmalltalkに失礼だな
0423デフォルトの名無しさん2008/10/03(金) 04:07:21
実用性皆無の実験言語が一般にアピールはないだろ
影響領域が違いすぎで失礼とかないわ
04244142008/10/03(金) 04:21:43
＞もっと高級でずっと生産性の高い言語とCを組み合わせるという
＞選択も普通にあるんだが、それも見えていないようだね
なんか偉そうに言ってるけど、C++は実行効率最優先の言語なんですが。
生産効率が良くて、速度やメモリ効率を犠牲にしてでも高級な機能を持つ言語が欲しいのなら
最初からC/C++は選択肢に入らないだろ。見えてないのはお前の方だ。
0425デフォルトの名無しさん2008/10/03(金) 04:34:31
その低劣な生産効率を補えるほどに速くすらないのが問題なんだろ

vtbl持たなきゃならないのはオブジェクト指向言語の本質的な非効率性だから
C++でも他でも一緒だしな
0426デフォルトの名無しさん2008/10/03(金) 04:39:32
他の言語は知らないが、GNUとMSのコンパイラは
純仮想関数を使わない限りVTBLは使われないよ
0427デフォルトの名無しさん2008/10/03(金) 04:54:09
そりゃ使わない物は使わないし、まともなコンパイラなら省くに決まってる

でも継承を有効利用するにはvtblはないわけにはいかない
継承と多態性はオブジェクト指向の根幹だ
0428デフォルトの名無しさん2008/10/03(金) 05:03:58
だから、継承とプリモにはVTBLは必要ないぞ
COMとか使ったこと無いか?アレだ
0429デフォルトの名無しさん2008/10/03(金) 05:07:31
インスタンスが自分が何者かを知らずにどうやってポリモやるんだ？
0430デフォルトの名無しさん2008/10/03(金) 05:11:22
オブジェクト指向がどうこうってより、同じような設計をしようと思ったら
Cでやっても同じようなコード（vtblと同じ、関数アドレスを介した呼び出し）になるわけで。
原理的に無理なものをどうこう言っても仕方無いだろ。

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

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

>>428
あまり詳しくないがCOMはvtbl使ってるはずだよ。
0431デフォルトの名無しさん2008/10/03(金) 05:14:35
>>430
そうそう
だから効率が重要な場合はあらゆるOO言語は使えないってこと
それはC++だろうとなんだろうと一緒な訳で
0432デフォルトの名無しさん2008/10/03(金) 05:26:13
勘違いさせたが、手続き型言語においてVTBLが必要となる一つの条件としてCOMを挙げた
手っ取り早くは適当にリバースエンジニアしてもらえればわかるのではないだろうか
あくまで、コンパイラの実装の話だけどね
0433デフォルトの名無しさん2008/10/03(金) 05:42:21
>>412,413
結局何も説明できずに馬鹿って言うだけなの？。なんなの？バカなんですか？
C++のなにが難しかったんですか？何がわからないのかわからないのですか？
0434デフォルトの名無しさん2008/10/03(金) 05:47:37
>>433
真性の馬鹿に何かを教える様な物好きに、そんな簡単にめぐり合えるとでも思ってるの？
0435デフォルトの名無しさん2008/10/03(金) 05:54:05
何か眠気でちゃんと読んでないのかな
C++は手続き型言語
要するに仮想関数程度じゃインスタンスを特定できるから
オーバーヘッドはCの関数を呼び出すのと引数分しか差がない

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

こんなもんで理解してくれ
0436デフォルトの名無しさん2008/10/03(金) 05:54:57
あ、ただのバカアンチなんですね。了解しました。テンプレートは難しいですもんね。
VisualBasicという言語をお薦めしておきます。
0437デフォルトの名無しさん2008/10/03(金) 05:59:09
＞要するに仮想関数程度じゃインスタンスを特定できるから
何だものすごいバカか
0438デフォルトの名無しさん2008/10/03(金) 06:01:23
>>435
仮想関数はvtbl使わなくて純粋仮想関数は使うって言ってるの？
本気で言ってるの？

よく眠って頭冷やせよ
0439デフォルトの名無しさん2008/10/03(金) 06:32:06
仮想関数批判はC++というかJavaとかC#とかもろもろ全部だしあんまし
意味ないような。
しかもそんな奴はむしろC++でメタテンプレートでも極めればいいし
C++向きだと思うが。
0440デフォルトの名無しさん2008/10/03(金) 06:47:47
OOの本質的なオーバーヘッドとC++固有の問題を
ごっちゃにして叩く輩が多いからな
0441デフォルトの名無しさん2008/10/03(金) 09:30:53
MFCはSTLが固まる前に発売されたから勝手に作った独自仕様などと言れれるゆわれはない。
0442デフォルトの名無しさん2008/10/03(金) 10:06:47
>>436
TMPなんぞを嬉しがってるのはC++信者だけだろ

パターンマッチングやダックタイピング／structural subtyping、
ファーストクラスの関数、lambda式、クロージャ
今時の高級言語がもっとマシな形で備えている機構が無いために
C++信者はあの醜く汚いバッドノウハウを金科玉条のごとくに
有難がってるんだろ
しかもC++からソースレベルでしか再利用できないというデッドな技術だから
C++信者はあくまでもC++にしがみつくしかない
タコツボだな
0443デフォルトの名無しさん2008/10/03(金) 10:26:23
>>442
>>436のアイデンティティが崩壊しちゃうからそれ以上言っちゃダメ
0444デフォルトの名無しさん2008/10/03(金) 10:35:40
>>442
お前みたいな流行りの言語機能好きは流行りの言語をそのときどきに勉強して
使ってればいいんじゃねーの？
Haskellでlambda使いまくりのWindowsプログラミングでもやってりゃいーじゃん。
なぜそれが現実的じゃないのか、なぜ誰もやってないのか、なぜ言語機能だけで
ソフトは作れないのかを知るといいと思うよ。
0445デフォルトの名無しさん2008/10/03(金) 10:38:54
>>444
Javaですらlambda式やクロージャを取り入れようとしてるのに今更何言ってんだ？
0446デフォルトの名無しさん2008/10/03(金) 10:45:19
>>444
自分に都合の良い解釈ばっかしてると馬鹿に見えるよ
0447デフォルトの名無しさん2008/10/03(金) 10:45:27
Cより古いLispをガン無視して単なる「流行」とか言ってるのが笑えるな
0448デフォルトの名無しさん2008/10/03(金) 10:46:53
連投乙
0449デフォルトの名無しさん2008/10/03(金) 11:01:49
>>445-447
そんなにむきになるなよ。お前は悪くない。時代が悪いんだ。
0450デフォルトの名無しさん2008/10/03(金) 11:04:37
>>449
いや、単純にお前の頭が悪いんだよ。
0451デフォルトの名無しさん2008/10/03(金) 11:11:46
お前らどんだけ馬鹿馬鹿言い合えば気が済むんだよｗ
0452デフォルトの名無しさん2008/10/03(金) 11:29:44
>>435
本当にC++を知っているとは思えない発言だな

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

こんなのは常識だろ
つーか、C++でどうやってポリモーフィズムを実現してると思ってるんだ
0453デフォルトの名無しさん2008/10/03(金) 11:32:37
自分の知っている処理系は全てvtblだが
C++にはvtblを用いて実装しなければいけないという決まりはなかったはずだが
0454デフォルトの名無しさん2008/10/03(金) 11:34:23
>>453
ああ、確かにちと実装より過ぎる説明だったか
いずれにせよ>>435が言っていることは明らかな誤り
0455デフォルトの名無しさん2008/10/03(金) 11:40:10
つっても店頭に並んでるアプリの9割はいまだにC++製だからなあ。
やっぱOSネイティブの言語は機能どうこう以前の強力さがあるんだよな。
まあC++にもlambda/bindが来年付くしまだまだ現役続投かねぇ。
0456デフォルトの名無しさん2008/10/03(金) 11:43:13
>>455
Windowsと同じだな
シェアそれ自体が最大の強み
言語が糞でもな……
0457デフォルトの名無しさん2008/10/03(金) 12:02:07
マイナーなもの使って人柱やるのもいやだしな
0458デフォルトの名無しさん2008/10/03(金) 12:03:28
>>417
C++ﾏﾝｾｰな俺も、それには同意。
0459デフォルトの名無しさん2008/10/03(金) 12:22:20
>>402以降、誰もC++の開発効率に触れないのな
0460デフォルトの名無しさん2008/10/03(金) 12:27:21
え、>>402以降リロードせず>>459を書き込んじゃったの？
0461デフォルトの名無しさん2008/10/03(金) 12:30:00
Office や Web ブラウザのような巨大で複雑なアプリをサクサク動かすには
今のところ C++ しか選択肢はないんじゃないか？ D はよく分からないが。
0462デフォルトの名無しさん2008/10/03(金) 12:36:04
>>460
具体的にどのレス？

ちなみに402は↓これだぞ？
>素朴な疑問なんだが
>C++がCより開発効率が良いって主張あるよな？
>ひとによっては暗黙の了解になってるぽいんだが
>それって誰がいつどうやって比べたの？
>ソースはあるの？
0463デフォルトの名無しさん2008/10/03(金) 12:36:48
MacではC++じゃなくてObjective-Cが母語なんだろ
だから、C++でなければならないというわけでは全くないだろう

少なくともOfficeみたいなリッチなOSの上に乗っかって動くアプリなら、
ネイティブコンパイルさえ出来れば、もっと動的な言語でも十分ってことになるん
じゃないのか
0464デフォルトの名無しさん2008/10/03(金) 12:44:53
>>462
単品のレスじゃなくて流れで分かるだろ

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

C++単品の生産効率についてなら腐るほど言い合ってるだろ
04654622008/10/03(金) 12:59:24
>>464
いや別に覆したいとは思ってないよ、事実関係をはっきりさせたいだけ
じゃあこのスレ的には「C++の開発効率はCより高いとは言えない」でFAだな
0466デフォルトの名無しさん2008/10/03(金) 13:15:19
>>465
大した根拠も無くC++の方が開発効率が良いと思ってる奴は確実に居るが、本当の所は誰も知らんがFA
0467デフォルトの名無しさん2008/10/03(金) 13:15:26
C++はCを内包するので比較する意味が無い
0468デフォルトの名無しさん2008/10/03(金) 13:18:04
また馬鹿が湧いた

C++はCを内包するので比較する意味が無い(ｷﾘｯ

いくらかマシに見える様に訂正しときました
0469デフォルトの名無しさん2008/10/03(金) 13:19:47
>>467
>>415
スーパーセットは時にサブセットに劣る
0470デフォルトの名無しさん2008/10/03(金) 13:25:17
スーパーセットである事によるオーバーヘッドが有意か否かは
開発者自身や処理系の問題であって言語の問題では無い
0471デフォルトの名無しさん2008/10/03(金) 13:26:26
カプセル化できるだけでも有難い＜C++
まあ「隠匿されたら処理の流れが解らんではないか！」とか
言い出す奴にとっては厄介なんだろうが。
0472デフォルトの名無しさん2008/10/03(金) 13:30:42
>>470
肥大化した仕様はまさに言語の問題だろう

さらにC++の場合は禿が実用性を謳ってるんだから開発者や処理系の都合も言語とセットで考えるべき
0473デフォルトの名無しさん2008/10/03(金) 13:34:32
C++ は基本的にサブセット(C部分)に劣らない。
C 部分の性能は普通の処理系なら落ちないから。
0474デフォルトの名無しさん2008/10/03(金) 13:43:43
>>473
流れ嫁よ
（実行時の）性能を比較してるわけじゃないだろ
0475デフォルトの名無しさん2008/10/03(金) 13:48:42
じゃあ、何が劣るの？
0476デフォルトの名無しさん2008/10/03(金) 13:52:41
「C++なんて駄目。Cの方がまし」という事にしたがっている奴の脳。
0477デフォルトの名無しさん2008/10/03(金) 14:06:15
C++ は C よりもコンパイラの選択肢が少ないところが劣っているかな。
俺はそんなことで困ったことはないけど。
0478デフォルトの名無しさん2008/10/03(金) 15:13:33
C++が一番ひどいのは学習コストだろう？
罠とバッドノウハウが多すぎる
そしてそこまでして学習したものは、C++を使うとき以外何の役にも立たない
だからこそ「バッドノウハウ」なんだけどな
0479デフォルトの名無しさん2008/10/03(金) 15:39:00
boostはC++を象徴してる
言語仕様の貧弱さを無理やりカバーするためにマクロとテンプレート使いまくり

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

プログラマの時間をドブに捨てさせるにはこれ以上ないいい言語だと思う
0480デフォルトの名無しさん2008/10/03(金) 15:41:44
標準でソケット通信ライブラリすら無いんだから規模はむしろ小さい方だろう
Cよりは当然覚える事は多いが
0481デフォルトの名無しさん2008/10/03(金) 15:56:55
C++作った理由の陰謀論みたいな話になってきたなｗ
0482デフォルトの名無しさん2008/10/03(金) 17:33:26
ねぇ、C++擁護派ってなんでこんな馬鹿なの？ねぇ、なんでこんな馬鹿なの？
0483デフォルトの名無しさん2008/10/03(金) 17:45:55
オブジェクト指向だけに、先人の思想を忠実に継承してるからな。
0484デフォルトの名無しさん2008/10/03(金) 17:48:07
反対派も大概バカだけどな
結局は適材適所
C++はアプリを作るには最低の言語
ドライバやミドルウェアを作る時にはそこそこ役に立つ言語
それでいいじゃないか
0485デフォルトの名無しさん2008/10/03(金) 17:54:49
お前らプログラムもろくに組めない癖に文句だけは一丁前に言うなｗ
0486デフォルトの名無しさん2008/10/03(金) 17:56:53
ツンデレなんだよ
0487デフォルトの名無しさん2008/10/03(金) 18:03:51
継承も例外もオーバーロードもテンプレートもなくして
クラスがメンバ関数とコンストラクタとデストラクタを使えるだけのちょっと便利な構造体なだけだったらよかったのに
0488デフォルトの名無しさん2008/10/03(金) 18:05:35
つか否定派と比べて擁護派が非論理的すぎるだろ
0489デフォルトの名無しさん2008/10/03(金) 18:10:17
特定分野では役に立つこともあるよねってだけで擁護派扱いか
ありとあらゆる局面で絶対に役に立たないクソ言語でないと気が済まないって人たちの方が怖いです
0490デフォルトの名無しさん2008/10/03(金) 18:13:46
ネイティブコンパイルできて、Cやasmのobjとリンクできるなら
何でもよくね？

組み込みに関しては、Javaみたいにエディション分けちゃえばいいのにと思う。
EC++とかは消えたんだろ？
0491デフォルトの名無しさん2008/10/03(金) 18:21:50
>>484
基本的に反対派の主張は>>484に書かれてる通りなんですけど？

馬鹿で非論理的な擁護派が勝手に>>489みたいに被害妄想炸裂させて
反対派の奴らはこんな極端な事を考えているキチガイだったんだよ！！！１１って五月蝿いだけなんです。
だから擁護派はなんか馬鹿が多いって言われてるんです。
わかりますか？
0492デフォルトの名無しさん2008/10/03(金) 18:26:11
>>441
そうだとしても、STLが策定された時点でSTLベースに作り直すのが筋だろ？
0493デフォルトの名無しさん2008/10/03(金) 18:30:23
>>492
MFCを作り直す必要はないんじゃないか？
モダンなC++として書けばATL/WTLのようにただの別物が出来上がるだけで
それに「MFC」という名前をつける必要がない

MFCの導入時はWin16からWin32への移行促進という目的があった
（ある意味今の.NETに似てる）
今や単なるレガシー技術の互換性サポートだろ
0494デフォルトの名無しさん2008/10/03(金) 18:34:06
>>492
どっちでもいいだろ
どうせウィンドウズが亡くなったらC++の使い道なんか殆ど無いんだしw
0495デフォルトの名無しさん2008/10/03(金) 18:36:38
>>492
準拠するに足る魅力が無かったってだけだろ
0496デフォルトの名無しさん2008/10/03(金) 18:47:19
MSC7.0だっけか
0497デフォルトの名無しさん2008/10/03(金) 19:23:44
>>492
そんな筋はないと思うぞ。
過去のMFCと互換性ぶったぎることになるだろうし。
0498デフォルトの名無しさん2008/10/03(金) 19:34:27
>>490
一応、ホスト環境とフリースタンディングって区分けが標準にある。
誰も意識していないけど……。
0499デフォルトの名無しさん2008/10/03(金) 19:57:41
492 タコ殴りw
0500デフォルトの名無しさん2008/10/03(金) 20:07:38
未来の言語

C{
ここC文法領域
}

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

Perl{
ここPerl文法領域
}

もうこんなのでいいよ
0501デフォルトの名無しさん2008/10/03(金) 20:10:31
むかしXMLでそんなことしてるのがあったな
0502デフォルトの名無しさん2008/10/03(金) 20:32:59
>>500
http://search.cpan.org/~ingy/Inline-0.44/Inline.pod
もっとだいぶ鬱陶しいけど、もう Perl にあるから全部 Perl でいいね。
0503デフォルトの名無しさん2008/10/03(金) 21:43:06
Союз Советских Социалистических Республик
0504デフォルトの名無しさん2008/10/03(金) 22:00:19
>>465
いろんな統計を見たことがあるはずだが、手元にある分では、行数に関するものしか見つからなかった。
Code Complete とラピッドデベロップメントに、ファンクションポイントあたりの行数が C の方が C++ に比べて 2.5 倍多いそうな。
0505デフォルトの名無しさん2008/10/03(金) 22:29:31
>>504
ただの興味なんだが、その「いろんな統計」が是非見てみたい。
個人的には「ファンクションポイントあたりの行数」では開発効率は測れない（根拠として弱すぎる）と思うし。
0506デフォルトの名無しさん2008/10/04(土) 01:23:33
>>492

確かに筋だな。
ttp://up2.viploader.net/pic2d/src/viploader2d465723.jpg
0507デフォルトの名無しさん2008/10/04(土) 01:36:10
↑面白い事をやったつもり
0508デフォルトの名無しさん2008/10/04(土) 02:13:47
>>494
言っておくが家庭用ゲーム機およびPCのゲームは殆どC++だぞ
一昔前はCで開発してるところも多かったが。
携帯ゲームはほとんどがJavaだが。
想像力無さ過ぎ。よくそれでプログラマやってられるな
0509デフォルトの名無しさん2008/10/04(土) 02:15:16
訂正、携帯電話のゲームは。
0510デフォルトの名無しさん2008/10/04(土) 08:36:46
どうして開発言語が C から C++ に移行したの？
0511デフォルトの名無しさん2008/10/04(土) 09:01:16
>>510
ゲーム開発の規模がデカくなり、プラットフォームをまたいで開発することが
増えるに従って、毎回書きなおしするような開発は非効率すぎるということで
業界全体がそういう流れになったんだと思う。
勿論Cでもマルチプラットフォームで使いまわしの利くコードは書けるけど、
それだけのセンスがあるなら、C++でプラットフォームをまたぐクラスライブラリを書けるし、
よっぽど解りやすくて保守しやすいコードになる。
かといって富豪プログラミングが許されるわけではないし（オブジェクトが裏でやっていることの
時間的・空間的コストが想像もつかないようでは話にならない）、アセンブリ叩く場面もあるけども。
中小では未だにCのところもあるみたいだけどね。
0512デフォルトの名無しさん2008/10/04(土) 12:41:29
>>511
なるほど。
ゲームでは C++ が C より生産性が高いということですね。
0513デフォルトの名無しさん2008/10/04(土) 12:45:37
一般論としては、OOが非常に適している分野とそうでもない分野があると思う
関数型が向いている分野とそうでない分野があるように

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

CでOOっぽいことも出来るが、デバドラぐらいならともかく
Xのツールキットぐらいの規模になると結構苦しい印象があるな
0514デフォルトの名無しさん2008/10/04(土) 13:56:46
>>512
待った、いちがいにそうとはいえない
業界最大手クラスのゲームデベロッパでは例外とSTLとBoostとRTTIとほぼ全ての演算子オーバーロードとほぼ全てのテンプレートが禁止だよ
その他の大手も大同小異だ
それってC++なのか？
0515デフォルトの名無しさん2008/10/04(土) 14:10:51
>>514
例外やBoostやRTTIはわかるが（コンシューマなら特に）、テンプレート禁止ってのはわからんな。
一体どこの会社を指して業界最大手とか大同小異だとか言ってるのか知らないが
クラス使ってりゃ十分C++だと思うけど。
まさかツール作るときもそれら全部禁止なの？
数値演算まわりのクラスにも演算子オーバロード禁止？
0516デフォルトの名無しさん2008/10/04(土) 14:12:06
C++を使わないと企画が通らないけど
C++を使うと開発が立ち行かない
0517デフォルトの名無しさん2008/10/04(土) 14:24:56
つーかさ、同じC++でも例外の有無でまったく別の言語だよな
コードの再利用なんて不可能なんだし
0518デフォルトの名無しさん2008/10/04(土) 14:29:55
>>515
不安定な俺クラスよりも、boostの同様なクラスを使ったほうがコードがすっきりしたりする。

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

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

ハゲが泥縄式に例外を導入した歴史的経緯なんでもうあきらめるしかないが
処理系提供側も例外使えないならC++を名乗らないで欲しい
0520デフォルトの名無しさん2008/10/04(土) 14:47:27
別に言語の全ての特徴を実際に使うかどうかは関係ないでしょｗ
使わないコードでもバイナリレベルにどうしても影響しちゃうとかならしょうがないけどｗ
0521デフォルトの名無しさん2008/10/04(土) 14:50:55
>>515
演算子やテンプレートは決められた人間が作ったものだけ使えっていうことじゃないかな。
例外を禁止する理由は良く分からないが処理系によっては例外を投げなくても重くなる
可能性があるからかな。
0522デフォルトの名無しさん2008/10/04(土) 14:55:12
コンストラクタの失敗とかはは例外以外のまともに捕まえる方法がないからな言語的に
結局errnoみたいなものに頼ることになって何のためのオブジェクト指向なのかという話に
0523デフォルトの名無しさん2008/10/04(土) 15:10:54
> 演算子やテンプレートは決められた人間が作ったものだけ使え

それって出来の悪い兵隊集めて仕事する三流請負業務系の発想だな
現在そういう系統ではC++は死滅していると認識しているが
0524デフォルトの名無しさん2008/10/04(土) 18:49:49
>>522
class hoge { ... };
hoge a;
if(!a.ok()) goto hell;

でいいんじゃね？
0525デフォルトの名無しさん2008/10/04(土) 18:53:59
お話になられません。
0526デフォルトの名無しさん2008/10/04(土) 19:18:06
といいますか、コンストラクタ内で自己完結してない時点でOOとしてはお話になりませぬ。
0527デフォルトの名無しさん2008/10/04(土) 19:26:18
ANSI C++ 1998
ANSI C++ 2003
ときて、
C++0
が採択される、まだまた拡張中。
0528デフォルトの名無しさん2008/10/04(土) 19:40:30
>>524
a の初期化に失敗した後は a は存在しないはず。
だから a にはアクセスできない。
0529デフォルトの名無しさん2008/10/04(土) 19:44:30
>>528
そこで言う「失敗」て例えば何なん？
0530デフォルトの名無しさん2008/10/04(土) 19:52:05
>>528
>>524は、iostreamのように、失敗しても例外を投げないような設計にしてある
ことが前提なんでしょ
0531デフォルトの名無しさん2008/10/04(土) 20:34:59
>>529
よくあるのがメモリ確保に失敗した時
0532デフォルトの名無しさん2008/10/04(土) 20:36:29
>>530
ああ、確かにそういう初期化に失敗しない設計もできるね。
しばらく RAII な設計をしてきたからそういうのは思いつかなっかた。
例外のない C++ だとクラス設計もかなり変わってくるな。
0533デフォルトの名無しさん2008/10/05(日) 00:00:41
某有名ゲームエンジンはC++でOOしまくり例外多用だけどね。
言語の文句ばっか言ってモノ作れないボンクラは原因は別のとこにあると思う。
0534デフォルトの名無しさん2008/10/05(日) 00:07:19
C++→肥大化
Ruby→肥満化
0535デフォルトの名無しさん2008/10/05(日) 00:12:10
Windows アプリ開発の主力言語が C から C++ になってしまったのは MS のせい？
MS に否定的な OpenOffice や Firefox まで C++ で開発しているみたいだけど。
0536デフォルトの名無しさん2008/10/05(日) 00:27:06
パソコン屋で売ってるソフトの90%くらいがWindows用
そのほとんどがVCで残りがVBかBCCかDelphi
0537デフォルトの名無しさん2008/10/05(日) 02:03:05
>>535
なんでもMSに結びつけるのは違うだろ。
0538デフォルトの名無しさん2008/10/05(日) 03:37:13
てか何年前の話だww
C#に移るのかって時代に
0539デフォルトの名無しさん2008/10/05(日) 03:47:22
ww
0540デフォルトの名無しさん2008/10/05(日) 03:59:28
>>533
>モノ作れないボンクラは原因は別のとこにあると思う。

モノ作れないのと言語の文句を言うのは全く別の話だと思う。
0541デフォルトの名無しさん2008/10/05(日) 04:52:27
結局擁護派って自分で書いたコードしか弄った事無いから擁護できるんだよな
発言から視野の狭さが見て取れる
0542デフォルトの名無しさん2008/10/05(日) 05:16:10
>>541
俺にはその擁護を否定に入れ替えるとその通りに思える
それともアレか、バカが書いたC++のコードを弄ってるとC++が嫌いになるとかか？
擁護否定に関わらず、バカが書いたC++のコードがクソなのは誰もが知ってると思うが。
0543デフォルトの名無しさん2008/10/05(日) 05:30:04
バカが書いた世界地図を思い出した
0544デフォルトの名無しさん2008/10/05(日) 05:44:08
>>542
これはひどい
0545デフォルトの名無しさん2008/10/05(日) 06:36:07
>>541
その文面からは視野の広さが見て取れない
0546デフォルトの名無しさん2008/10/05(日) 10:07:57
スレタイとどんどん離れてくなｗ
0547デフォルトの名無しさん2008/10/05(日) 10:43:15
ただのバカスレだしな
0548デフォルトの名無しさん2008/10/05(日) 10:53:15
スレの趣旨とは合致してるからまったく無問題
すぐ顔真っ赤になるC++信者を見守るスレです
0549デフォルトの名無しさん2008/10/05(日) 11:44:56
アンチまっさお、信者まっか
0550デフォルトの名無しさん2008/10/05(日) 13:08:17
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
0551デフォルトの名無しさん2008/10/05(日) 13:09:17
C++ のようにマルチパラダイム言語はプログラミングが楽だ。
複数の言語でプログラム断片を作ってつなぎ合わせる方法は結構面倒くさい。
0552デフォルトの名無しさん2008/10/05(日) 13:24:05
C++のプログラミングが「楽」とか正気とは思えん
LLなら数行で済む仕事に一体何行かける気だ

言語は適材適所で使えよ
ネイティブなobjを吐く言語は要するに高級なアセンブラなんだからよ
0553デフォルトの名無しさん2008/10/05(日) 13:50:23
末端作業員はPerl永遠にやってな
0554デフォルトの名無しさん2008/10/05(日) 13:51:47
１つのプログラムは GUI からレイトレの計算までいろいろな部分が混在してる。
これらをそこそこカバーできるメジャーな言語は C++ 以外に何がある？
そのぞれの部分に得意な言語を使うこともできるがリンクが面倒くさくなる。
0555デフォルトの名無しさん2008/10/05(日) 13:53:40
低所得スクリプターが紛れ込んで奮闘してるんだろ。
0556デフォルトの名無しさん2008/10/05(日) 14:02:41
厨房はこれだから困る

今時ゲームだってLuaだのPythonだのスクリプトエンジンの一つや二つ
入れ込んでるだろ
gaucheの作者はスクウェアでCGのプロダクションシステムをLispで書いてる
というかLispは昔からCG分野で主流で、今はPythonが取って代わっている
Emacsは実際にはLispインタプリタで、だからこそあれだけ強力なエディタなんだ
0557デフォルトの名無しさん2008/10/05(日) 14:08:44
馬鹿が書いたコードは言語問わず糞だが
他言語に比べてC++は馬鹿が糞コードを非常に書きやすい
しかもC++では優秀な開発者でもバッドノウハウを身に付けないと危険なコードの罠にはまる
0558デフォルトの名無しさん2008/10/05(日) 14:35:18
C++&Python最強ということで終了
0559デフォルトの名無しさん2008/10/05(日) 15:16:54
>>556
それはかなり金をかけて作られるゲームエンジンに統合されているからできること。
普通のアプリでそういうことをやろうとするとデバッグも含めてかなり面倒くさい。
COM や .NET で多言語のリンクをしたほうがまだまし。

C++ は C が得意な部分、OO が得意な部分、テンプレートなどを自然な形で結合できる。
これを作った禿は天才
0560デフォルトの名無しさん2008/10/05(日) 15:28:53
C++ に慣れちゃったからそれが自然なだけでしょ。
「言語は人間を規定する」という訳だ。
0561デフォルトの名無しさん2008/10/05(日) 15:38:13
>>559
「普通のアプリ」とやらが何をさしてるんだかわからんが
趣味で作ってるおもちゃのフリーソフトのことなら、好きにすれば？
趣味なんだしな
0562デフォルトの名無しさん2008/10/05(日) 16:17:12
説得力のある話を披露できない代わりに
相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
と、相手の顔の色を一所懸命空想したところで、
誰もその人を支持しないどころか、むしろ発言者の顔の色が
そうなってるという印象を持つだけだと思う。
0563デフォルトの名無しさん2008/10/05(日) 16:37:54
>>552
ちゃんとした仕組みを作り上げれば、楽になるのだと思う

でも･･･　ねぇ、、　その時間と楽さのトレードオフがなってないよ
それに気づけない人がC++にのめりこんじゃうと本当に時間無駄にしてる
それが楽しいならいいけど
C++は、根底だけ用意して土台が何も無いから･･･
そういう人が土台を一生懸命作ってる感じ
あと、何年したらまともな土台になるのやら
0564デフォルトの名無しさん2008/10/05(日) 17:02:09
>>552
Cやアセンブラと比較すれば、相対的にまし程度のことだと思う。
0565デフォルトの名無しさん2008/10/05(日) 17:15:45
C++のデストラクタのような頑強な後処理をCを使って手作業で書くことを考えるとうんざりしてしまう。
0566デフォルトの名無しさん2008/10/05(日) 17:23:24
>>563
仕組みというのがライブラリのことを言ってるんなら無駄
簡単な話だ、アセンブラにライブラリやマクロを山ほど乗っけたら幸せになるか？
アセンブラはどこまで行ってもアセンブラだよ
C++も同じことさ
0567デフォルトの名無しさん2008/10/05(日) 17:46:55
でも、Cと同じようにも書けるから
上手くC言語拡張として使うだけなら、良いと思うんだけどなぁ（俺はそう使ってる
ベターCから抜け出せない？　なんとでも言うが良いよ

だから個人レベルでC++使うのはいいけど、大勢でC++使うのは勘弁です....
0568デフォルトの名無しさん2008/10/05(日) 17:54:05
ベターCとは言うけどどの辺がベターなの？
OOとか例外とかテンプレートとか演算子オーバーロードとか便利（ということにしたがってる）な機能を
全部捨ててなおCよりベターな所って何？
0569デフォルトの名無しさん2008/10/05(日) 17:54:21
引きもっこりがなにいってんだか
0570デフォルトの名無しさん2008/10/05(日) 17:59:17
>>567
>大勢でC++使うのは勘弁です....

激同。
何がベターかは人それぞれだから、足並みを揃えるのが大変そう。
0571デフォルトの名無しさん2008/10/05(日) 18:05:01
C の方が大勢で使うのは勘弁
アクセス制御やデストラクタがないのは危なかしい。
0572デフォルトの名無しさん2008/10/05(日) 18:10:50
そんな些細な便利機能のためだけに他の爆弾を大量に持ち込む方が馬鹿げている
0573デフォルトの名無しさん2008/10/05(日) 18:13:56
だから571のところでは、テンプレート禁止とかいろいろ制約かけるんでしょ？
それだけで572の言うところの爆弾を抑えきれるかどうかは知らないけど。
0574デフォルトの名無しさん2008/10/05(日) 18:25:12
テンプレートやインライン関数の代わりにマクロ使いまくるほうが爆弾
例えば C++ にはどんな爆弾がある？
0575デフォルトの名無しさん2008/10/05(日) 18:30:41
いまさらC++がむずいとか・・ww・・ゆとりには確かに無理www
0576デフォルトの名無しさん2008/10/05(日) 18:30:43
C のマクロと C++ のテンプレートの使用頻度が全く異なるのは見ない振りですか?
0577デフォルトの名無しさん2008/10/05(日) 18:30:56
つーか、実際というか仕事の場合、ライブラリとかでどうせ制限されるんだから、
言語がどうのってのはないだろｗ

いくら優秀な言語でも誰も知らんかったら、実用性ゼロだｗ
0578デフォルトの名無しさん2008/10/05(日) 18:42:20
マクロなんて簡単だろ
所詮文字列の置き換えなんだから挙動も明確だしあとからいくらでも追跡できる

テンプレートはカオスすぎて人間が追いかけるのは不可能
0579デフォルトの名無しさん2008/10/05(日) 18:46:12
テンプレートもmplまで行くと
チャーチ数とかbrainf*ckとかgrassみたいなのに似たノリを感じる

パズル好きが趣味で遊ぶオモチャとしてはいいんだろうけどな
0580デフォルトの名無しさん2008/10/05(日) 18:46:30
いつからテンプレートが危険視されるようになったんだ。
テンプレートメタプログラミングなら分からないでもないが
そもそも理解できていないやつがそんなもの作るとも思えないし。
0581デフォルトの名無しさん2008/10/05(日) 18:48:15
>>578-579
Boost.Preprocessorもやばい。
0582デフォルトの名無しさん2008/10/05(日) 18:52:33
テンプレートはデバッガがデバッグをサポートしているからまだいいよ。
普通マクロはデバッガで追跡できない。
0583デフォルトの名無しさん2008/10/05(日) 18:53:03
>>568
型チェックがしっかりしてるところ。
0584デフォルトの名無しさん2008/10/05(日) 19:16:15
>>582
デバッガで追えなくて困るほどマクロを多用する事は無い
テンプレートとは違う
0585デフォルトの名無しさん2008/10/05(日) 19:18:01
テンプレートはtypedefの奥底にいつ潜んでるかわからないからな
マジで地雷と変わらん
0586デフォルトの名無しさん2008/10/05(日) 19:45:03
Cの場合同じような処理を繰り返し書くからマクロなんてそんなに使わないよ。
0587デフォルトの名無しさん2008/10/05(日) 19:50:34
いい加減、C++使ってるとにコストがペイ出来ない状況になってる事に気付いたら？
ドライバや3Dゲーム、フレームワーク作ってる人らはいいんだけど、それ以外のヌケサク共はさ
0588デフォルトの名無しさん2008/10/05(日) 19:57:43
Cでメタプロっぽいことをやるときは
他言語でのソース生成／(cppではない）プリプロセッサを使うのが常道だろう
cppは貧弱だから、出来ることもたかが知れている

>>587
なぜそこで「フレームワーク」ｗ
フレームワークビジネスってのは上に乗っかる馬鹿な兵隊がいるから
成り立つもんだろう
0589デフォルトの名無しさん2008/10/05(日) 20:17:20
弱小の無名詐欺フレームワークは含んで無いよ
0590デフォルトの名無しさん2008/10/05(日) 21:30:02
Cでマクロなんかほぼ使わないし見ないぞ
マクロが危険て奴の職場はどんだけレベル低いんだ？
そんな奴らはCだろうがC++だろうが変わらんだろう
0591デフォルトの名無しさん2008/10/05(日) 22:38:11
たまに他のプログラマが作ったマクロと識別子がぶつかって悩まされる。
ひどいときは小文字1文字のマクロがあって原因の特定に時間がかかる。
UNIX のヘッダーでさえ major とか定義していてわけが分からなかった。

そのほかにも引数が複数回評価されたり、型がチェックされなかったりすることがある。
0592デフォルトの名無しさん2008/10/05(日) 23:03:03
じゃあ名前ぶつかってもオーバーロードで華麗にスルーするC++は最悪ですね
0593デフォルトの名無しさん2008/10/05(日) 23:05:51
>>591
全部、殆どありえないケアレスミスじゃん…
0594デフォルトの名無しさん2008/10/05(日) 23:12:08
>>592
型に従うから大丈夫。名前空間使うから他人のものとぶつかる確率は低い。
>>593
他人が作ったものだから避けられない。
0595デフォルトの名無しさん2008/10/05(日) 23:15:27
いや、避けられないとかじゃなくてさ、そんな状況は現実世界じゃ発生しないのよ。
「たまに」とか「ひどいとき」とかいうレベルじゃない。
0596デフォルトの名無しさん2008/10/05(日) 23:20:46
何を言っても今後 C++ が良い言語に生まれ変わる訳でもないし、
世間の評価が上がる訳でもないから仕方が無いね。どうしても
必要なら使うけど、そうでなければごめん被りたい。
0597デフォルトの名無しさん2008/10/05(日) 23:29:13
>>595
594は別世界の人間なんだから、お前はそっとしてやれ。
0598デフォルトの名無しさん2008/10/05(日) 23:30:38
C++のネイチブコンパイル出来たら西京
0599デフォルトの名無しさん2008/10/06(月) 00:04:49
MIN(x,y)とかMAX(x,y)を標準のCプリプロで副作用無しで書けるか？
0600デフォルトの名無しさん2008/10/06(月) 00:10:34
C++擁護派はCのスーパーセットって何度も主張してるけどさ
だったら>>591の問題は全てC++でも起こることになるよ
当然それにプラスしてC++固有の問題も起こるから、Cより問題点が多いってことになっちゃうよ
0601デフォルトの名無しさん2008/10/06(月) 00:12:19
>>599
C99にはinlineがある
現在でも(C99対応してなくても)主要なコンパイラはほぼ対応済み
0602デフォルトの名無しさん2008/10/06(月) 00:21:10
>>600
スーパーセットをマイナス方向にしか考えないのか？
C++はマクロの問題を解決できる機能をいくつか追加している。
inline, template, namespace など。
0603デフォルトの名無しさん2008/10/06(月) 00:35:10
templateｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
マクロの問題の100倍以上大問題な機能ですねｗｗｗｗｗｗ
0604デフォルトの名無しさん2008/10/06(月) 00:37:25
東京から品川へ行くのに新幹線を使う様なもんだな
0605デフォルトの名無しさん2008/10/06(月) 00:45:58
>>602
いや、むしろ逆でしょ
擁護派が都合の良い時だけスーパーセットを主張してるみたいだから
都合の悪い部分もちゃんと継承しろって言ってるだけ

大体さ>>591が言うような
>ひどいときは小文字1文字のマクロがあって原因の特定に時間がかかる。
↑みたいな奴がC言語の問題点として挙がってるけどさ、
そいつはC++使ったって小文字１文字のマクロを定義するでしょｗ
むしろC++ならもっと素敵な大惨事になりそうだと思わない？
0606デフォルトの名無しさん2008/10/06(月) 00:49:08
マクロといえば誰もが知ってるのがmin/max問題だろう
0607デフォルトの名無しさん2008/10/06(月) 00:49:58
>>600に対して>>602のレスって・・
C++擁護派は都合の悪い意見はわざと間違った解釈で話題を逸らそうとしてるように見える
それとも本当に理解出来ないほど頭が悪いのか？
0608デフォルトの名無しさん2008/10/06(月) 00:50:12
>>596
だからお前にとって良くないだけで、お前が使わなきゃいいだけ。
Swingでぐだぐだなアプリでも作ってろって。
C++みたいな技術者としての基本スキルが扱えないワンランク下の技術者と
して生きていけばいいだろ。
0609デフォルトの名無しさん2008/10/06(月) 01:01:01
他人の書いたコードはどうしようもないし、
605の「そいつはC++使ったって小文字１文字のマクロを定義するでしょｗ」も絶対に間違いない。

だけど、少なくとも自分の書く部分ではC++の機能でマクロを回避できば、
その分マクロの問題に遭遇する可能性は低くなるはず。
もちろん、使い込むとそっちの機能で問題に出食わす羽目になるが。
0610デフォルトの名無しさん2008/10/06(月) 01:13:15
小文字１文字のマクロを定義する奴なんかにC++使わせたら
何気なく足し算する時も「もしかしてこのoperator+引き算してんじゃねえだろうな」って
いちいち怯えながら使わなきゃならなくなるじゃねえか
0611デフォルトの名無しさん2008/10/06(月) 01:18:22
C++アンチは些細な問題を避けるためにどんだけ利便性捨てているんだよ。
0612デフォルトの名無しさん2008/10/06(月) 01:23:56
マクロ云々はどうでもいいが
ABIの問題などは、本来低レベルの道具作りにはずのC++としてはちっとも
些細な問題じゃない

だからMSはCOMみたいな物を作ったが
COMは結局糞だったので.NETにとってかわりつつある
.NETの提供する相互運用性を横目に、C++は、自分に閉じたテンプレートの
世界だけで生きて行こうとしているわけだな
0613デフォルトの名無しさん2008/10/06(月) 01:25:39
>>608
C++ への批判を "C++ を使えない" という話に都合良くすり替えるなよw
それに、"C++ は難しい" という前提で話すのもそろそろ止めようぜ
Perl と同じで汚いだけなんだから
0614デフォルトの名無しさん2008/10/06(月) 01:32:47
一部の狂信者がアンチはC++理解出来ないことにしたがってるのが萎える
このスレを見る限りアンチはC++を理解した上で批判してる
擁護派のひとは的外れでないC++の批判や問題点はきちんと受け止めよう
それで利点欠点を天秤に載せてC++を使う使わないの判断は勝手にすればいい
0615デフォルトの名無しさん2008/10/06(月) 02:00:03
お互い考え方が違うんだから、お互い論理的な説明をしても話がかみ合わないのは当然。
0616デフォルトの名無しさん2008/10/06(月) 02:11:08
そもそも嫌いならだまって使わなきゃいいだけなのに、基地外C++アンチが粘着してる
ように見えるけど。
0617デフォルトの名無しさん2008/10/06(月) 02:12:05
スレタイ読めよ
0618デフォルトの名無しさん2008/10/06(月) 02:22:23
ここは不可避で理不尽な思いをした職業プログラマの愚痴履き場

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

ま、経験した事無いんだから想定できなかったとしても馬鹿とまでは言わないよ
ただ、その自己陶酔した妄言と違って「現実に起こっている事」なんだという事くらいは覚えておいて欲しい
0619デフォルトの名無しさん2008/10/06(月) 03:01:15
>>615
あきらかに擁護派の方が非論理的なレスが多い、
アンチが化けてるのかってぐらい擁護派はおかしい。
何度も指摘されてるし、スレ読み直すと一目瞭然だよ。
0620デフォルトの名無しさん2008/10/06(月) 03:22:53
lambdaとかmplとか1文字マクロとか現状のコードではほとんど問題にならないような
ものを取り上げた批判が論理的には感じないけどね。
C++はCとの互換性とか、ゲームからデスクトップアプリから組み込みから科学技術
計算まで想定してる汎用言語だし、歴史も長いから情報量も膨大だし、自分に必要な
ものだけを上手に取捨選択できる経験値が求められるのは確かだし、そういう意味で
難易度が高いと思うよ。
0621デフォルトの名無しさん2008/10/06(月) 08:02:28
自分に必要なものの判断なんて別に難しくないし、そんなこと非論理的な擁護派意外誰も論じてない。

難しいのは知りもしない他人が必要としたものの判断。
C++ではこれが壊滅的に終わってる。
0622デフォルトの名無しさん2008/10/06(月) 08:41:21
なんか頭悪そう
0623デフォルトの名無しさん2008/10/06(月) 10:22:58
とりあえず、頭悪い奴にC++を扱うのが無理だということだけは分かるｗ
0624デフォルトの名無しさん2008/10/06(月) 11:13:26
>>620
ABIの問題とか色々まともな批判も出てるだろ
見たくないものには目をつぶってどうでもいい批判しかないと
片付けたがっているようにしか見えんよ
0625デフォルトの名無しさん2008/10/06(月) 11:30:38
C++の代わりに何を使えばいいというのだろう。
0626デフォルトの名無しさん2008/10/06(月) 11:48:17
初心者がやたらポインタ使いまくる症状になんか似てね？


今の時代、絵を描くのだって、いくらだって大きな紙は用意できるけど
だからって欲張って全部使おうとする事はないと思う･･･
ハサミというものを用意してちょっとずつ切って使えばいいんだよ！
人が作ったものを人が使いこなせないってことが、今リアルにC++で起こってる
0627デフォルトの名無しさん2008/10/06(月) 12:07:16
Dに注目が集まったのはC++への不満の裏返しだな
まあDはDで別の理由でポシャったけどな
0628デフォルトの名無しさん2008/10/06(月) 12:14:14
JavaもC++を否定して注目集めた
0629デフォルトの名無しさん2008/10/06(月) 12:18:15
とりあえず、自分の意見は論理的って思い込みを捨てるんだ
ここまでで論理的な意見なんて一個も出てないからww
0630デフォルトの名無しさん2008/10/06(月) 12:22:45
>>628
Javaはサーバーサイドアプリケーションの分野ではC++を追い落としたな
それだけだが
0631デフォルトの名無しさん2008/10/06(月) 12:25:08
C#ぐらいの言語仕様＆開発環境の成熟度で
Delphiのようにネイティブコンパイル＆スタティックリンク可能な環境があれば
いいんだがな
0632デフォルトの名無しさん2008/10/06(月) 12:53:12
>>624
> 見たくないものには目をつぶって
>>619みたいな人のことですね。
0633デフォルトの名無しさん2008/10/06(月) 12:58:09
>>619
本当に何度もそんなことが「指摘されてる」なら、それってつまり、
一方的で自分に都合のいい「指摘」を何度もするのが、このスレの否定派ってことだよね。
「俺よりアイツのほうが明らかに馬鹿」って言う、あまりに幼稚で痛々しい意見を、
擁護派より否定派のほうがたくさんしてるっていう証言だよね、これ。

自爆してない？
0634デフォルトの名無しさん2008/10/06(月) 13:10:08
>>631
つcrossnet
0635デフォルトの名無しさん2008/10/06(月) 13:15:44
例えばさ、近いところだと
>>590 >>591 >>600 >>602 >>605
ちょっと長いけどこの流れ見てどう思う？
どうみたっておかしいよね？
0636デフォルトの名無しさん2008/10/06(月) 13:21:02
しかもそれに対して>>620ではさらに
>lambdaとかmplとか1文字マクロとか現状のコードではほとんど問題にならないような
ものを取り上げた批判が論理的には感じないけどね。
これもありえない
擁護派はこの手のすり替えとかごまかしが多いって言われてるわけだ
0637デフォルトの名無しさん2008/10/06(月) 14:35:27
C++は言語屋やハッカーからは大抵嫌われている
という印象を持っているんだが、偏見かね

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

仕方なく我慢して使うような言語なら自然と消えていくだろう。
OS と違って言語は開発側が選択しやすいんだから。
0639デフォルトの名無しさん2008/10/06(月) 15:43:03
ハッカーにとってみればメモリの実際の内容が気になるだけだから
いちいちコンパイラに文句言われてreinterpret_castとか書くのが面倒になるんじゃないかな。

ところで否定派は「バカが書いたライブラリや同僚のバカが書いたコードに
煩わされるから＆その上、上からC++使えと強制されるから」
とかそういう理由で嫌ってる人が多いような気がするんだが。
C++を嘆くよりその会社を辞めることをお勧めしたい。
そもそもC/C++はプログラマを信用して、誤用よりも利便性を優先してるんだから
バカに書かせたらダメなんだと何回言わせｒ（ｒｙ
0640デフォルトの名無しさん2008/10/06(月) 15:56:29
>>638
> 仕方なく我慢して使うような言語なら自然と消えていくだろう。
> OS と違って言語は開発側が選択しやすいんだから。

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

Cとの互換性は、C++を広める上では一番の強みであり、
同時に言語の中身だけ考えれば最大のネックにもなっている
0641デフォルトの名無しさん2008/10/06(月) 18:47:47
擁護派は>>638みたいな意見を見てもおかしいと思えないの？そんな馬鹿なの？
0642デフォルトの名無しさん2008/10/06(月) 18:56:12
>>630
携帯のアプリも
0643デフォルトの名無しさん2008/10/06(月) 19:02:26
C++を嘆くよりその会社を辞めることをお勧めしたい。(ｷﾘｯ
0644デフォルトの名無しさん2008/10/06(月) 19:08:31
> バカが書いたライブラリや同僚のバカが書いたコードに煩わされるから

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

もっとも、型付けだけ強くても、型推論してくれるわけでもねーし
JavaやC#ほどインテリセンス向きでもねーし
テンプレートを使えばコンパイルエラーはあっさりゲシュタルト崩壊するし
reinterpret_castとか長々とタイプさせたところで
相変わらずC++で自分の足を撃つのはこれ以上ないぐらい簡単なんだけどな
0645デフォルトの名無しさん2008/10/06(月) 19:26:37
>>641
世界中の言語屋より禿一人が正しいと思ってるんだから仕方が無い
信者というのはそういうものだ
0646デフォルトの名無しさん2008/10/06(月) 19:39:08
gccとテンプレートは分けて使うことにしたらいい。
またはgccを使わない。
あら不思議、C++がとっても素敵な言語に。
0647デフォルトの名無しさん2008/10/06(月) 20:00:43
逆に言えば、新しい言語を作ったとしてどの言語で実装する？
0648デフォルトの名無しさん2008/10/06(月) 20:06:35
>>638
逆に、今でもC++は消えていないということは、
仕方なく我慢して使うような言語ではないとも言える。
>>630>>642が挙げたように消えたところもあるし、今現在消えつつある分野もまた。

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

>>647
Cじゃね？
0649デフォルトの名無しさん2008/10/06(月) 20:22:53
VCとか6時代に比べりゃ格段にマシにはなってるんじゃね
Dinkumwareは相変わらずっぽいし
セキュアCRT絡みがなにげにウゼーけどな
0650デフォルトの名無しさん2008/10/06(月) 20:46:44
C++ が消えていないのは、商用のコンパイラが整備されているとか、
ライブラリが沢山あるとか、ネイティブに落とせてそれなりの速度が
出るとか、機能をつまんで使うならそこそこ便利だとか、C と互換性が
ある程度考慮されているとか、まぁ色々理由があるよね。

C++ に消えてもらいたい理由もごまんとあるけど、代わりの言語を
提示するのは中々難しい。既に Java で置き換えられた分野もあるけど、
D とか ObjC とかはまだまだだよね。C + LL とかが最有力候補かな。
最近は C++ + LL とかもあるから安心出来ない。
0651デフォルトの名無しさん2008/10/06(月) 20:53:52
うちの会社はみんなうれしそうに C++ 使っているぞ。
顧客から無理やり C 使わせられたときはみんなブーブー文句言っているぞ。
0652デフォルトの名無しさん2008/10/06(月) 21:02:36
>>651
なんか可愛いなｗ
0653デフォルトの名無しさん2008/10/06(月) 21:16:07
「擁護派」でレス抽出すると粘着がいることがよく分かる。

C++に醜い部分があるのは確かだが、
後発の方がきれいなのは当たり前だろう。
Dでマングリングが統一されているのはイイと思うけど、
マイナーすぎて実用する気にはならないね。
0654デフォルトの名無しさん2008/10/06(月) 21:19:02
マングリングとか小学校で教えられないだろ
用語選べよな…
0655デフォルトの名無しさん2008/10/06(月) 21:20:42
名前がエロい
0656デフォルトの名無しさん2008/10/06(月) 21:22:54
そうなんだよなあ。C++ は醜い。出来れば使いたくないもんだ。
演算子のオーバーロードなんて無い方がスッキリする。
0657デフォルトの名無しさん2008/10/06(月) 21:43:58
VC8SP1はDinkumwareが気に入らないんだが、かと言ってtr1を標準装備
したので今更STLportに戻る気も起きないし・・
0658デフォルトの名無しさん2008/10/06(月) 21:48:33
VC9の話かな？
Dinkumwareは糞だと分かっててももういいやって感じだな
boost他とのからみもあるし

_SECURE_SCLってみんな切ってるのかね？
0659デフォルトの名無しさん2008/10/06(月) 21:53:04
>>656
いや、演算子の多重定義は要る。C++のは改良の余地がありまくりだが。
0660デフォルトの名無しさん2008/10/06(月) 21:54:17
>>658
あ、ごめんなさい
VC9SP1でした。
0661デフォルトの名無しさん2008/10/06(月) 22:35:26
演算子のオーバーロード嫌がるのってJavaの人くらいかと思ってるんだが違うのかな
オーバーロード可能な言語どころか追加定義できる言語もあるわけで

あとテンプレート悪玉論唱えてる人は簡単なアプリでもいちいち自前で各型向けのlistとか作ってるの？
どうしてる？
0662デフォルトの名無しさん2008/10/06(月) 22:52:54
>>661後
そういうことを主張する人は、そもそも動的型付けか何かで
テンプレートがなくても問題ない言語を使っているんだろう。
0663デフォルトの名無しさん2008/10/06(月) 23:02:11
たんなる総称型なら持っている言語は多いとは思うが
C++のテンプレートとは別モンじゃないか？
C#やJavaのGenericsも違うしな
0664デフォルトの名無しさん2008/10/06(月) 23:06:11
>>663
日本語読めないの？
0665デフォルトの名無しさん2008/10/06(月) 23:06:40
コンセプトをインターフェースにすればいいだけだろ。
0666デフォルトの名無しさん2008/10/07(火) 00:12:49
テンプレートが悪いって言ってる人間はテンプレート全く使ってないと思ってるの？
0667デフォルトの名無しさん2008/10/07(火) 00:25:20
coutとかstringとか
ありふれた道具の裏にことごとく潜んでるサブプライムローンみたいな存在ですから
0668デフォルトの名無しさん2008/10/07(火) 01:07:56
>>659
Lisp とか Smalltalk みたいに、関数と演算子の区別が無い言語なら何やっても良いよ。
C++ みたいな言語に入れるのは間違いの元だと思われ。
0669デフォルトの名無しさん2008/10/07(火) 01:12:55
STL, boost, 自分で作ったテンプレートも特に問題なく便利に使えてるんだから
テンプレートに問題があってもかまわない。演算子も。
0670デフォルトの名無しさん2008/10/07(火) 01:15:04
&&と||のオーバーロード許可してるのは明らかな設計ミスだろ
遅延評価持ってないくせに
0671デフォルトの名無しさん2008/10/07(火) 01:17:07
そういう人間とチームで開発すると苦労しそうだから嫌というか不安。
C++ だと最初にルールを決めても破綻しそうだな。
0672デフォルトの名無しさん2008/10/07(火) 01:19:00
お、済まん。>>671 は >>669 向けね。
0673デフォルトの名無しさん2008/10/07(火) 01:27:25
>>666
嫌なら使うなよ
0674デフォルトの名無しさん2008/10/07(火) 01:40:58
ぶっちゃけるとテンプレートの問題より>>669みたいな奴が開発に関わる事の方が問題がある
0675デフォルトの名無しさん2008/10/07(火) 01:51:50
C++は問題があるから使わないってやつはどれほどチーム開発で試してきたんだよ。
C,C++は仕事でそれぞれ20,15年ぐらい使ってきが、ここ5年ぐらいC++特有の問題は
たいして起きていないぞ。けして優秀な人間ばかり揃えているわけではない。
新卒でいきなりC++使わせているけどそれほどひどい使い方はしていないよ。
むしろCで作らせたほうが間違いが多いぞ。
0676デフォルトの名無しさん2008/10/07(火) 01:54:21
テンプレートやらオーバーロードやらを自由に使わせてそれなら
相当優秀な人間が揃ってるか、問題を認識できないボンクラばかりかのどっちかだな
0677デフォルトの名無しさん2008/10/07(火) 01:55:57
>>670
Lispで言ったらspecial formとprocedureをごっちゃにしてるようなもんだよな
かなり笑える話だ
0678デフォルトの名無しさん2008/10/07(火) 02:17:43
LispはC++の代わりにならないからな。
0679デフォルトの名無しさん2008/10/07(火) 02:20:30
>>678
意味分かんないで反応してるだろ

関数呼び出しが引数を全部先に評価しちまう正格評価のくせに
&&や||を関数にしちまうなんてのは、
情報系の学部学生でもやらないレベルの誤りだろ
0680デフォルトの名無しさん2008/10/07(火) 02:23:38
なんでC++は難しいって事になって
C++を悪く言う奴はC++を使ってない(使えない)って事になってるんだ？

いや、そこまで強烈に決め付けできる幸せな脳みそだからC++使ってて幸せなのか＾＾；
0681デフォルトの名無しさん2008/10/07(火) 02:37:49
C++は完璧でこの世で最も優れた言語なんだ！！！！
C++に欠点なんか無い！！
だからC++を悪く言う奴はC++を理解出来ないに違いない！！！！
って考えてるからだよ^^
0682デフォルトの名無しさん2008/10/07(火) 04:24:22
あんまりレベルが違い過ぎると、合わせるのに疲れ果ててしまうのがC++の厄介なところ。
0683デフォルトの名無しさん2008/10/07(火) 04:32:49
>>679
何を問題にしてるのかさっぱり分からないのは確かだけどな。
0684デフォルトの名無しさん2008/10/07(火) 04:43:10
operator&&を組み込みの&&演算子と同じ挙動にすることは絶対に出来ないんだぞ
ひどい話だろ
0685デフォルトの名無しさん2008/10/07(火) 04:48:59
前10レス読んだだけの脊髄反射レスだけど
万全でなければ使えないようにするというのも、またどうかとも思うけどね
論理演算子でトラブッた事はない訳で
コードする側が保障する必要のあるものは、便利にする過程でどうやっても登場するよ。
これらはテストツールの充実で解決して欲しいね。
0686デフォルトの名無しさん2008/10/07(火) 04:50:01
あ゛ーC++にテストツールとか無茶もいい所か・・・
スレタイ読まずでした
0687デフォルトの名無しさん2008/10/07(火) 05:16:10
>>684
More Effective C++に書いてあるね
0688デフォルトの名無しさん2008/10/07(火) 08:41:14
>>684
誰も使ってない部分の話はどうでもいい
0689デフォルトの名無しさん2008/10/07(火) 08:51:14
中途半端な使用を放置してる事は問題なのに、どうでもいいとか問題無いとか…
問題を見てない振りしてるくせに、使ってない奴はレベルが低いとか…
0690デフォルトの名無しさん2008/10/07(火) 08:53:38
使用→仕様、ね。変換ミスした。
0691デフォルトの名無しさん2008/10/07(火) 09:00:20
>>689
で、問題になったことは？
多重継承のがずっと問題あるのに全く話題にあがらないのが不思議なんだけど

本質を突かない話なんか本当にどうでもいい
0692デフォルトの名無しさん2008/10/07(火) 09:03:39
そんなの本質じゃないごっこはどうでもいいけど、
問題を上げればきりが無いのが C++ だな。
0693デフォルトの名無しさん2008/10/07(火) 09:06:16
>>692
素直にこれ豆知識なって書いておけばよかったのに
顔真っ赤かよww
0694デフォルトの名無しさん2008/10/07(火) 09:07:29
問題があるから使わないのに、俺は問題と認識してないからと
突っ走る奴が居るのが問題なんだよな…
0695デフォルトの名無しさん2008/10/07(火) 09:14:44
>>693
どう見ても君の顔が真っ赤だし、なんか歯軋りとかも聞こえますよ。
打鍵の音もなんか凄そうですｗ
0696デフォルトの名無しさん2008/10/07(火) 09:17:29
突っ走るって何のこと？
誰も使ってない(=使うことではない)のだから…うん？

抽象的な表現に逃げられると途端に意味がわからん

俺はこんな仕様知ってるんだぜ大会ではないんだぜだぜ
0697デフォルトの名無しさん2008/10/07(火) 09:21:32
>>695
怒った時の君の顔が浮かんだ
普通の人は頭に血がのぼっても歯ぎしりなんかしない
0698デフォルトの名無しさん2008/10/07(火) 09:22:47
>>695はもうキーボードの前にいるのか
仕事しろw
0699デフォルトの名無しさん2008/10/07(火) 10:16:33
なんか校則がギッチギチのＤＱＮ学校の生徒が、
校則ゆるゆるの進学校に対して、お前のところはルールがゆるすぎるから学校の治安が悪くなるって喚いてるイメージｗ
0700デフォルトの名無しさん2008/10/07(火) 10:26:45
>>683
int i=0;
if (i++ || i++) {
printf("%d", i);
}

0701デフォルトの名無しさん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++は糞の山になっているんだぞ
0702デフォルトの名無しさん2008/10/07(火) 11:32:25
誰も見えてなくないじゃん。 使わないからどーでもいい、って言ってる。
んなこと言い出したらCだって過去の負の遺産が大量に残っているが。
0703デフォルトの名無しさん2008/10/07(火) 11:35:17
>>702
「お前は」どうでもいいかもしれないが「言語としては」どうでもよくないんだよ

実装者にはその無用なものを実装するコストがかかり
教育者にはその無用なものを使ってはいけないと教えるコストがかかり
学習者にはその無用なものを使わないように学ぶコストがかかり
ユーザにはどこかの馬鹿が罠にはまったかどうかをチェックするコストがかかる
0704デフォルトの名無しさん2008/10/07(火) 11:37:37
> Cだって過去の負の遺産が大量に残っているが
墓穴だな

C++はCとの互換性のために、その負の遺産を全て引き継いだ上で
比較にもならないほど多くの落とし穴を自分で掘っているのだから
0705デフォルトの名無しさん2008/10/07(火) 12:54:10
まぁ、批判するにも代替手段を提示して欲しいわなｗ
畢竟どの言語もみんなしょうがなく使ってるわけだしｗ
0706デフォルトの名無しさん2008/10/07(火) 13:11:11
細かいところまで見たらウンコな仕様があるのはどの言語もだいたい一緒だと思うぞ

Javaだってウンコだらけだし
0707デフォルトの名無しさん2008/10/07(火) 13:24:32
問題はC++のうんこは臭すぎることなんだよね
形は整ってるかもしれないけど飛び散りすぎてるし
0708デフォルトの名無しさん2008/10/07(火) 13:33:29
そもそもCが糞なんだから、C++が糞なのは自明。
0709デフォルトの名無しさん2008/10/07(火) 14:38:21
>>705
なんで代替手段を提示する必要があるわけ？
言語の批判は批判でいいじゃん
それと他の言語が糞だからってのも関係が無い
0710デフォルトの名無しさん2008/10/07(火) 15:54:05
C++が糞言語でないと気がすまないらしいな。
0711デフォルトの名無しさん2008/10/07(火) 15:59:52
>>709
結局のところ、みんなC++は糞だと思いつつも、ほかの言語はさらに糞なので
一番まともで最高なC++を使ってるわけだよ。
で、もっといい言語があるなら乗り換えたい。
しかし、そんなものはないので仕方なくC++を使ってるわけさ。
そういう状況下で、「C++は糞」とか主張しても「で、もっといい言語あるの？」
って聞き返されるのは当然でしょ。
関数型言語にはものすごい期待したんだけど、使ってよかったと思える状況って
CGIとか程度じゃない？
CUI全盛の時代だったらいっぱい使い道あったんだろうけどね。
結局、糞だ糞だと思いつつもC++を使うしかないわけ。
だって今ある中では最高の言語だからね。

で、もっといい言語あるの？
0712デフォルトの名無しさん2008/10/07(火) 16:01:08
ひどい釣りだな
0713デフォルトの名無しさん2008/10/07(火) 16:05:51
>「で、もっといい言語あるの？」
>って聞き返されるのは当然でしょ。
用途もなにも前提なしで「いい言語あるの？」と聞き返すのは
そりゃ莫迦にとっては当然かも知らんが。
0714デフォルトの名無しさん2008/10/07(火) 16:07:38
>>713
だってC++は用途を問わず最高の言語だからね。
CGIを書くには最適ですっていう言語があったとしても代替にはならないでしょ。
そう思わない？
0715デフォルトの名無しさん2008/10/07(火) 16:12:56
換言すれば、C++で出来ることは全てカバーしていなければ代替にならない。

で、もっといい言語あるの？
0716デフォルトの名無しさん2008/10/07(火) 16:14:30
釣りもいいけどageないで欲しいな
0717デフォルトの名無しさん2008/10/07(火) 17:01:55
>>694
突っ走るって、現実に&&や||を定義するやついるのか？Boost.Lambdaくらいしか知らないが。
.や.*と同じようにこれも禁止しなかったのは間違いだと俺も思うが。

>>705
C#のture/false演算子はC++の&& ||よりましだと思う。
0718デフォルトの名無しさん2008/10/07(火) 17:35:54
禁止するよりも力尽くでも本物と同じ動きに出来るようにするべきだった。
0719デフォルトの名無しさん2008/10/07(火) 17:45:32
ageている奴は発言が面白すぎるので愉快犯と見た

&&はテンプレートの中で型が確定できない状況で使ったらセマンティクスが
全く不明になってしまうね
それはショートサーキット評価されるのだろうか、されないのだろうか？
0720デフォルトの名無しさん2008/10/07(火) 18:09:15
>>701
言いたいことは判るけどさ、それで問題が起こるようなケースってのは
コピーやキャストされてしまうような時だけであって、そうなるかもしれないってのが頭にあるなら
できる限り避けましょうと、参照にしたりすればよく、逆に高速化が必要ならオーバーロードしたりテンプレート化したりして個別対応すればいい訳。
実用上の障害は何一つないのに問題視するのは、それ自体問題だ。
0721デフォルトの名無しさん2008/10/07(火) 18:14:02
>>719
テンプレートはコンパイル時に型が特定されるので、問題はないのでは？
動的なテンプレートを実装したりすると問題が起こると思うけどC++はそうではないし。
0722デフォルトの名無しさん2008/10/07(火) 18:17:41
>>721
勿論テンプレートを実体化するときには確定するな
が、テンプレートは静的ダックタイピングの手段だから、
関数テンプレートを記述する際には型に関する仮定はおけんだろ？
で、&&はどうすりゃいいんだろうな
&&が腐ってるんなら、仕方なくVBみたいにifのネストを使うか？
0723デフォルトの名無しさん2008/10/07(火) 18:20:36
C++最大の問題はプリプロセッサと旧態依然のコンパイル・リンクだろうな、あれの存在のお陰で
自動テストは作れない作ってもショボイ、インテリセンスも作れない作ってもバカの極み
自動リファクタリングに至ってはもはや絶望的、しかもコンパイルもリンクも超低速という点。
0724デフォルトの名無しさん2008/10/07(火) 18:35:14
>>722
それが問題になるような事態に直面した事はないが、仮に直面してどうしても困るなら
type_traits でも使えばよいのではと俺なんかは思ってしまいます。
0725デフォルトの名無しさん2008/10/07(火) 18:41:57
>>724
議論ずれてきてるな
こんな風にすればカバーできるよ！ってのどんどん突き進めたのが
TMPなりboostなりだろ

いやそれはあんたはそれでいいのかもしれねーけどよ
大したことやってるわけでもねーのに、あの糞ったれなバッドノウハウ集
全部押し付けんのか？プログラマに

&&の問題なんて、禿の設計誤りさえなければそもそもそんなことを
考える必要すらないんだぜ
0726デフォルトの名無しさん2008/10/07(火) 18:43:26
>>725
それ以前に困った事態ってのはどんな事態なんだよ、俺はそっちの方が気になる。
0727デフォルトの名無しさん2008/10/07(火) 18:46:53
>>726
俺は困ってねえよ
ユーザ定義&&なんてつかわねえからな
自分では

が、テンプレート関数の中の&&は、一種の時限爆弾のようなもんだろ
誰かがユーザ定義&&を用いたら、それはコンパイルエラーにはならず
不可解な実行時の問題を引き起こす、かもしれない
そして、それはすぐには気づかれない、かもしれないわけだ
0728デフォルトの名無しさん2008/10/07(火) 18:50:27
それが心配でたまらないなら、ある種病気だよ
0729デフォルトの名無しさん2008/10/07(火) 18:53:03
実際、「C++の仕様で爆弾発生率が高い」ってのがソースなさすぎだからなｗ
0730デフォルトの名無しさん2008/10/07(火) 18:54:32
流石にそれはないよｗ
ただ、俺はそういう問題を知るためにまたしても＊無駄な＊コストを払わされたがな

みんな麻痺してんじゃねえのか？
C++の要求するあまりの学習コストの高さとバッドノウハウの多さに
確かにこんなのは氷山の一角ですらねえよ
もともとが糞の山過ぎてな
0731デフォルトの名無しさん2008/10/07(火) 18:57:11
危険だと分かっているものであれば自然、用心深く取り扱われるので、思ったほど事故は起こらないもの。
面倒臭いだけだから何とかしろとは思うが、それらの問題点に突っ込み入れても問題は出てこないだろうね。
C++逝ってよし派ではあるんですが、重箱の隅をつつくような問題点指摘には賛成できない。
0732デフォルトの名無しさん2008/10/07(火) 18:57:54
お金もらえるならなんでも書くよ
0733デフォルトの名無しさん2008/10/07(火) 19:08:41
>>727
まあ、もしそういうことが起こったら、&&を定義したユーザの方が悪いだろということにされるな。
やっぱりなんでこんなの定義できるようにしたんだって話ではあるが。
0734デフォルトの名無しさん2008/10/07(火) 19:15:29
ヘッダファイルに
static int int_data;
#define x int_data
などと比べれば&&など些細な問題さ
0735デフォルトの名無しさん2008/10/07(火) 20:21:24
&&と||は避けようと思えば避けられた問題だもん
演算子はとにかく全部オーバーロードできるというわかりやすい規則を優先して
その中には危険な演算子もありますよという話ならまだわかる
でもそうじゃないじゃん
例えば&&と同じく副作用完了点を持つ?:はオーバーロードできない
::は出来ないし.も.*も出来ない、sizeofもtypeidもthrowも出来ない
どれも問題あるからわざと出来ないようにしてるんだ
どうしてこのリストの中に&&と||を加えることが出来なかったんだ？
つーか?:を出来なくした時に気付けよ禿
0736デフォルトの名無しさん2008/10/07(火) 20:42:31
えんざんしちげーだろ
0737デフォルトの名無しさん2008/10/07(火) 20:44:22
そんなに気になるなら、&&セーフとか&&FREEのシールでも貼っとけ。
0738デフォルトの名無しさん2008/10/07(火) 20:51:51
>>729
>実際、「C++の仕様で爆弾発生率が高い」ってのがソースなさすぎだからなｗ
EffectiveC++等々の存在は十分爆弾発生率の高さを証明してると思うが・・
0739デフォルトの名無しさん2008/10/07(火) 21:00:38
EffectiveJavaもあって、初級者用じゃないけどJavaプログラマの中ではかなりの必読の部類に入るよ。
0740デフォルトの名無しさん2008/10/07(火) 21:16:14
組み込み系の経験ないんですが、C++使用の場合って
コーディング規約とかで縛ったりするものなんでしょうか？
0741デフォルトの名無しさん2008/10/07(火) 21:18:14
もう一つ問題がある演算子があって、それはカンマ演算子
&&や||などと同じく、やはり副作用完了点として働く演算子の一つだ
普通は逐次実行されるので、左辺も右辺もどのみち評価されるから気にすることは少ないが
左辺が例外投げるような場合はやはり同じような問題が起こる

さて、なぜoperator,は定義できてしまうのか？偉大なるBjarne大先生の答えはこうだ

＞operator,をオーバーロードできるようにしたのは、そうしてはいけない理由がなかったからだ。
(C++信者の聖典、D&Eより引用)

これはひどいｗｗｗｗｗｗｗｗｗ
0742デフォルトの名無しさん2008/10/07(火) 21:19:58
ある分野では operator , が実用上離せない
0743デフォルトの名無しさん2008/10/07(火) 21:25:34
>>739
それ関係なくね？
0744デフォルトの名無しさん2008/10/07(火) 21:31:32
>>741
なんつうかおじいちゃんはもっといたわって隠居させるべきだと
思ってしまうな
0745デフォルトの名無しさん2008/10/07(火) 22:05:12
いけなかったというより、::や.のような制約がなかったからと言うべきのような……。
0746デフォルトの名無しさん2008/10/07(火) 23:54:42
>>727
核戦争の心配してるほうがお似合い
そっちのほうが被害は甚大だし現実にあり得る
0747デフォルトの名無しさん2008/10/08(水) 00:11:43
結局、使いこなせない人が「この要素が悪いんだボクが悪いんじゃないやい」
って言い訳しつつ、使いこなせる人をデタラメに煽って射精するスレってことでおｋ？
0748デフォルトの名無しさん2008/10/08(水) 00:21:39
operator&&なんて使いこなしちゃいけない機能です
0749デフォルトの名無しさん2008/10/08(水) 00:25:31
問題点を指摘されて、それがありえる・ありえないって話にすり替えるのは違うんじゃないか
問題はあるけど回避可能だからC++を使おうって判断はそれぞれの職場でやればいい
だけどココで問題を指摘されてるのに、自分にとってありえないから問題じゃないってのはお話にならないよ
0750デフォルトの名無しさん2008/10/08(水) 00:33:41
>>747
また同じ煽りパターンか
ぼくちんのC++に文句いうやつらは全員C++理解できないに違いない！
C++も禿もぼくちんも天才！欠点なんかあるわけない！
これで満足？
0751デフォルトの名無しさん2008/10/08(水) 00:36:09
何でもルールのせいにするのはゆとりだろう。
0752デフォルトの名無しさん2008/10/08(水) 00:40:30
C++ しか知らなければ、C++ を過大評価したくもなるんじゃないかな。
2ch で主張してる分には見掛け上はノーリスクだし。
0753デフォルトの名無しさん2008/10/08(水) 00:54:36
747みたいに突然流れ無視して
「アンチはC++使いこなせないんだ！」って暴れ出す厨が定期的に出てくるよな
正直、どっちサイドからみても邪魔な基地外なんだがw
0754デフォルトの名無しさん2008/10/08(水) 01:02:39
テンプレートメタプログラミング禁止とか多重継承禁止とか
実際に実行出来てる例はあるのかな。ベターCとして使う事を
考えるなら当たり前に出来て欲しいんだけど、どうも揉めそうだ。
他にも例外禁止とか名前空間禁止とか演算子のオーバーロード
禁止とか、Boost禁止とか、RTTI禁止とか。
0755デフォルトの名無しさん2008/10/08(水) 01:15:19
>>750
君って低学歴でしょ？
0756デフォルトの名無しさん2008/10/08(水) 01:31:45
>>754
禁止する理由を納得のいくように説明すれば揉めないんじゃない。
0757デフォルトの名無しさん2008/10/08(水) 01:49:11
>>749
&&なんてC++使っているほうからしたら、誰も使わないだろjkって話なんだが、
外から見たら、ようするにバッドノウハウなんだよな。
そこに温度差というか埋まらない溝を感じた。
0758デフォルトの名無しさん2008/10/08(水) 01:55:05
>>754
うちは揉めないけど、やっぱりみんな言語仕様通しの関連が分かってないね
まあ新人はいまどきCなんて嫌だろうし、
ちゃんと理解して使うならC++でもいいよーって許可するんだけどね
ミスらなかった子はひとりもいない、ベテランでもミスる
もちろん仕事だからフォローはするよ
0759デフォルトの名無しさん2008/10/08(水) 01:55:58
誰も使わないし誰も使っちゃいけない機能が何であるんだよという素朴な疑問があるだけです
まあ設計者が大した考えもなしに使えるようにしちゃってるだけだけど
0760デフォルトの名無しさん2008/10/08(水) 02:09:42
>>741
カンマの左辺で例外が起きたときの問題ってどんなの？
0761デフォルトの名無しさん2008/10/08(水) 02:14:53
>>760
ただの関数呼び出しでは評価順序は決まっていないから、
a, bでoperator ,関数が呼び出されるときには、
b, aの順で評価されても構わないということになるはず。
0762デフォルトの名無しさん2008/10/08(水) 02:22:18
>>749
なら誰にとってありえるの？
使いこなせないくせに演算子オーバーロード機能使って、しかも&&演算子を…
っていう人間を仮定してみるとあちこち矛盾が生じるのだけれど
使いこなせるのに…もまた然り
0763デフォルトの名無しさん2008/10/08(水) 02:59:50
>>762
え？釣りなの？本当に理解できてないの？
0764デフォルトの名無しさん2008/10/08(水) 03:12:41
いいかい
問題がある・ないってのは客観なんだ
問題がありうる・ありえないってのは主観なんだ
客観に対して主観で反論したら議論にならないだろう？
これはC++とか関係ない当たり前のことだよ
0765デフォルトの名無しさん2008/10/08(水) 03:21:30
>>762
釣りじゃないなら一晩おいて、もう一度よく読み返してみな？
大丈夫、C++の問題点よりずっとずっと簡単な話だよ
0766デフォルトの名無しさん2008/10/08(水) 03:56:33
Javaだと回避不能なウンコ仕様が多くて困るけど
（例えばしょうもないことで例外が飛んでくるとかthrowsとか）
C++のウンコは知ってれば回避可能なウンコが多い気がするな

まあ確かにC++にはウンコ満載な気はするけど
知ってしまえばどうということはないので
慣れればあまりフラストレーションが溜まらない、というのが俺の実感

&& || , のオーバーロードの話だって
More Effective C++ に「やるな」と書いてあって、
簡単に納得できるレベルの話だしねえ
0767デフォルトの名無しさん2008/10/08(水) 04:07:11
いやいや、中にはそもそもできないようにしろよって主張も上の方にあっただろ。
俺もそう書いた1人だよ。
0768デフォルトの名無しさん2008/10/08(水) 04:15:20
>>766
>>764に書かれてる事なんですぐ繰り返すの？ねえ？なんで？ばかなの？しぬの？
0769デフォルトの名無しさん2008/10/08(水) 04:35:23
CGIしか作れないようにしたらC++の意味ないよな。
ｳｹﾙｗ
0770デフォルトの名無しさん2008/10/08(水) 08:59:01
包丁は販売禁止ですね
わかります
0771デフォルトの名無しさん2008/10/08(水) 09:47:29
いや、別に包丁は売ってもいいし、包丁で人が切れてもいいけど、

包丁を使ったと思ったら菜箸だった（ﾎﾟﾙﾅﾚﾌAAry

となるのがC++の凄いところ
0772デフォルトの名無しさん2008/10/08(水) 09:55:57
>>770
両刃の包丁を買ってきたと思ったら、背側にも刃がある両刃でした
0773デフォルトの名無しさん2008/10/08(水) 10:52:24
>>766
> Javaだと回避不能なウンコ仕様が多くて困るけど
> （例えばしょうもないことで例外が飛んでくるとかthrowsとか）

これはウケた

以下のコードはf()は何もthrowしない、と例外仕様で言っているが、
f() throw() { throw 1; }
これをあんたのコンパイラがどう扱うか確認してみればいい

C++では文字列も整数もクラスも
ポインタも参照も、何でもthrowできる
例えばMFCとVC++のCOMサポート、C++標準ライブラリのようなものは
当然のように全く異なる流儀で例外を扱っている
それらを全て捕まえたければ catch (...) を使うしかないが、
これでは何が飛んできたか分からないから、事実上何の役にも立たない
勿論スタックトレースの取得などできるわけもない

C++はJavaの例外を馬鹿にできる立場には一切無いよ
0774デフォルトの名無しさん2008/10/08(水) 11:25:14
>>769
operator &&や||をなくしただけで
CGIしか作れなくなるのか

すげえ言語だな
0775デフォルトの名無しさん2008/10/08(水) 12:44:13
|| のオーバーロードは昔からあるんだから現実にこの世の中で問題が起きたことを
確認してから批判してくれ。
どうせ || のオーバーロードができなければできないで批判されるだろうから。
0776デフォルトの名無しさん2008/10/08(水) 13:50:33
まあほんとは仕事なんててきとーにJavaみたいな言語でやってるのが楽なんだがなあ
0777デフォルトの名無しさん2008/10/08(水) 14:28:45
>>773
例外仕様の話は当然知ってるよ
何が起こるかもよーく知ってるし、
色んな本に「使うな」と書いてあることもだ
使わなければ簡単に問題は回避できるだろ？

>それらを全て捕まえたければ catch (...) を使うしかないが、
それぞれどんな例外が飛んでくるかわかるんだから
個別にcatchすればいい
Java で catch (Exception e) がまずいのと同様に
catch (...) は原則として使っちゃだめ
両方ともまったく同じ問題を抱えている

スタックトレースについては仕方ないんじゃない？
そもそもC++の規格は実行スタックの存在すら仮定してないし
余計なデバッグ情報をバイナリに入れないと取得不能だしね
0778デフォルトの名無しさん2008/10/08(水) 14:39:08
>>777
ん？Javaの例外がウンコでC++のはそうじゃないんだろ？

一貫性がなく事実上使いものにならない例外仕様
共通のインタフェースの欠如
スタックトレースの欠如

これだけでもJavaの例外より劣ることは明白だが
何をもってC++がウンコでないと言っているんだ？


0779デフォルトの名無しさん2008/10/08(水) 14:52:55
> Java で catch (Exception e) がまずいのと同様に
> catch (...) は原則として使っちゃだめ

上と下ではまったく意味が違うんだが。
たしかに「製品クオリティの」コードでは上は避けるべきだが
下とは違い、最低限Exceptionクラスを通して得られる情報だけは
得られる。スタックトレースやエラーメッセージなどがな。

下はゼロだ。完全に。
はっきり言って、こんなものを捕まえるぐらいならクラッシュしてくれたほうが
マシだよ。コアダンプをバックトレースしてみればどこで落ちたかわかるからな。
0780デフォルトの名無しさん2008/10/08(水) 14:57:05
>>778
>>766 をよく読んでくれ
C++の例外がウンコじゃないなんて書いてないぞ
むしろC++にはウンコがいっぱいと書いてある
0781デフォルトの名無しさん2008/10/08(水) 15:06:36
C++はウンコだらけで臭くて臭くてしょうがないけど、踏まなければ関係ないねって事だよな

そんじゃお前は家の前に毎日ウンコしていく犬が居ても関係無いのかって話だわ

批判してる奴は別にウンコ踏んで怒ってるんじゃなくて
クセエよ片付けろよ、てか初めからウンコしてんじゃねえよって文句言ってるんだよ
0782デフォルトの名無しさん2008/10/08(水) 15:11:20
横レスだが

C++がウンコ満載なのは納得した
あんたはウンコ全部よけれるんだぜーて言うけどさ
普通はそんなウンコ満載言語には近づきたくないよw
特にこれからプログラムを学ぶ人間ならな
0783デフォルトの名無しさん2008/10/08(水) 15:41:00
横から悪いけど、Javaのthrowsって何がウンコなの？それって一般的な認識？
0784デフォルトの名無しさん2008/10/08(水) 15:43:38
>>783
どうせthrowsとかいつも書かされるのが嫌だ、とかいう下らない理由だろう
Javaは例外をインタフェースの一部とみなしているから
はっきり宣言させているのだし、C++よりずっと首尾一貫しているわけだが

C++では関数might_throw()が例外を投げるかどうかを確認するには、
それについているドキュメントを信用するか、それから呼ばれる
コールツリーを全ておっかけるしかない
0785デフォルトの名無しさん2008/10/08(水) 15:46:28
>>783
比較的どうでもいいことまで例外投げてきやがってウゼエって個人的感想じゃないの？
必ずキャッチしなければならないから回避不可って
0786デフォルトの名無しさん2008/10/08(水) 16:04:41
○○は糞とか、○○はウンコとか言う奴ってさ
大抵の場合、一つの言語しか使えないような低脳野郎だよね
0787デフォルトの名無しさん2008/10/08(水) 16:50:20
>>784,785
あぁ、なるほど。スレの流れから考えて、C++に対するウンコは客観的な意味っぽかったから
Javaに対するウンコも同様だろう、と思ったら違ってたのか

要は、流れとは全く関係なく、
Javaは強制される作法が多くて疲れるが、C++はそれがなくていい、って言いたかっただけか。
0788デフォルトの名無しさん2008/10/08(水) 17:34:02
ここ数百レスのすれ違いまとめ

批判側
　C++ウンコだらけで臭すぎ、マジ臭い

擁護側
　ウンコを踏む奴はただの馬鹿ｗｗｗ
　大体そんな道の端にあるウンコ誰が踏むんだよｗｗｗ
　だからC++には全く問題がないｗｗｗ
　ウンコを避けれる俺カコイイｗｗｗ

批判側
　いや、それじゃ臭い事実は変わらないから･･･
0789デフォルトの名無しさん2008/10/08(水) 17:37:30
>>783
http://www.ibm.com/developerworks/jp/java/library/j-jtp05254/
> チェック済み例外に対するいくつかの批判
•チェック済み例外が、実装の詳細を不用意にさらけ出している
•不安定なメソッド・シグニチャー
•読みとれないコード
•例外の飲み込み
•例外ラッピングが多すぎる
0790デフォルトの名無しさん2008/10/08(水) 18:08:50
大暴落のおかげで腐りかけてたN225のプットワラントが
20倍近くになってうまうまなんだが。
0791デフォルトの名無しさん2008/10/08(水) 22:32:23
信者：C++の何が問題なのか言ってみろ！
アンチ：&&や||をオーバーロード出来る事に問題がある
信者：そんなの普通は使わない、だから問題無い！
アンチ：新人が絶対それ使わないってあんたが保障してくれるの？

信者：北朝鮮の何が問題なのか言ってみろ！
アンチ：核ミサイルを持ってることに問題がある
信者：そんなの普通は使わない、だから問題無い！
アンチ：正日が絶対それ使わないってあんたが保障してくれるの？
0792デフォルトの名無しさん2008/10/08(水) 22:39:26
安全かどうかはこの際どうでもいいんだけどね
不愉快で醜いウンコには俺の前から消えて欲しいだけで
0793デフォルトの名無しさん2008/10/08(水) 22:45:03
C++の例外がヤバイってのは分かるとしても、|| && の批判はバカじゃねえのと思わずにはいられない。
0794デフォルトの名無しさん2008/10/08(水) 22:45:46
世界恐慌～WW1
　アメリカ->ニューディール政策
　ロシア->共産化
　その他→植民地補充合戦

もうお分かりですね？
0795デフォルトの名無しさん2008/10/08(水) 22:48:06
核なら怖いが、破裂しないバクチクに安全保障などしなくて良い
0796デフォルトの名無しさん2008/10/08(水) 22:53:02
C++ のヤヴァイ所は全部ストラウストラップのチェックを通って世に出されたんだよね？
0797デフォルトの名無しさん2008/10/08(水) 22:54:16
D&Eを見る限り、興味ない所はろくにチェックしてないようだがな
741のように
0798デフォルトの名無しさん2008/10/08(水) 23:09:53
そもそも罠で作ったってどこかで言ってたよ
0799デフォルトの名無しさん2008/10/08(水) 23:17:47
本当にわかってないのかな？
&&のオーバーロードなんてのはあくまでも例であって
問題点を認められない狭量さを揶揄されてるんだよ

「自分は平気だからそれは問題ではない！」
こんな主張がアリなら、どんな糞言語のどんな糞仕様でもなんでもアリになってしまう
0800デフォルトの名無しさん2008/10/08(水) 23:19:09
坊主憎けりゃ袈裟まで憎いとw
0801デフォルトの名無しさん2008/10/08(水) 23:20:42
つーかそこは設計者の資質自体が疑われるところだろ
実害の有無以前の問題として、あまりにアホすぎてな
情報系の学生の演習問題レベルのミスだ
禿はラリっていたとしか思えない
0802デフォルトの名無しさん2008/10/08(水) 23:35:14
スティールやヴィルトみたいなプロの言語設計者が作った言語じゃないからね。
悪態付いても祈っても、最早どうしようもないし、取り返しも付かない。
0803デフォルトの名無しさん2008/10/08(水) 23:37:35
perlなんてミスの権化だな、使える言語だが。完璧主義など糞くらった方が良い
C++否定派の俺からしても、こういう愚かな批難は同意しかねますね。
0804デフォルトの名無しさん2008/10/08(水) 23:39:24
いやPerlなんて普通に使わないが。
もっとマシな「Perlのようなもの」があふれているからな。
0805デフォルトの名無しさん2008/10/08(水) 23:42:01
>>791
ミサイルは取り返しがつかないが、ソフトウェアなら取り返しがつく。
＃頼むから新人は取り返しのつくようなところに使ってくれ。
0806デフォルトの名無しさん2008/10/08(水) 23:43:15
Perl と C++ は似てるよね。汚いから嫌われている。
0807デフォルトの名無しさん2008/10/08(水) 23:45:40
また話のすり替えかな
0808デフォルトの名無しさん2008/10/08(水) 23:47:16
今、話のすり替えの話にすり替えた人を見た
0809デフォルトの名無しさん2008/10/08(水) 23:47:53
>>805
>>799
0810デフォルトの名無しさん2008/10/08(水) 23:48:30
C#がネイティブ吐けたら終了
0811デフォルトの名無しさん2008/10/08(水) 23:49:22
>>810
それ、あんまり意味無いと思うよ
今だってngenでネイティブコンパイルできるが
C++の代用にはならない
0812デフォルトの名無しさん2008/10/08(水) 23:56:58
MFCってやつに取って代わることは出来るかもな
0813デフォルトの名無しさん2008/10/09(木) 00:08:38
>>799
なら、どういう書けば問題を認めるってことになる？

実際問題、&&は反論しようのないことだ。
どうせ禿のことだ、今更&&禁止とかやるわけがない。
C++を使う側としては、使わない、つまり運用で回避するしかないという現状を述べただけ。
たしかに顔真っ赤にしているようにしか見えないのがほとんどだったが。
0814デフォルトの名無しさん2008/10/09(木) 00:18:18
反論しようの無いことだと思ってるんなら
別に黙ってればいいだけじゃね？
0815デフォルトの名無しさん2008/10/09(木) 00:34:11
だってさ、誰も使っていない（と思っている）ことでそんなに言われるとさ、つい。

逆に、例外では沈黙に傾いていたと思うよ。
使っていて実感しているから、こっちこそ何も言えない。
0816デフォルトの名無しさん2008/10/09(木) 00:51:34
仕様はともかく、危険なのはコンパイラでデフォルト動作で禁止すればいいだけの気はするがｗ
0817デフォルトの名無しさん2008/10/09(木) 01:31:50
operator&&くらいなら簡単に警告出せるだろうけど、危ない機能はまだまだあるからな
継承ハイジャックとか
0818デフォルトの名無しさん2008/10/09(木) 01:38:19
>>813
言語に問題があることを認めた上で、「黙って」運用で回避する
たったそれだけのことじゃないかな

例えば>>749はアンチだが最初からこう言っている
>問題はあるけど回避可能だからC++を使おうって判断はそれぞれの職場でやればいい
0819デフォルトの名無しさん2008/10/09(木) 01:42:14
それなりにC++のノウハウが高い会社にいくとC++の例外は上手に使ってるよ。
ゲーム関係とか。罠を避けつつ、うまく例外クラスライブラリとかスタックトレースとか
組み上げてる。
そういうノウハウをその辺の入門書読んだだけじゃ上手に学べないという罠が
あるけど。
0820デフォルトの名無しさん2008/10/09(木) 01:47:24
いや何と言っても #define private public が一番危ないｗ
0821デフォルトの名無しさん2008/10/09(木) 01:49:17
RTTI はともかく、ゲームや組み込みでは、まだ当面、例外はいらんだろう。
0822デフォルトの名無しさん2008/10/09(木) 01:59:14
ゲームといってもPCとコンシューマじゃまるで状況が違うよ
環境によって例外はそもそも使用禁止だったりするし
合理的な会社は当然マルチプラットフォーム前提で作るから例外は使わないね
0823デフォルトの名無しさん2008/10/09(木) 02:00:12
Album Title : 恋、はじめました！（OP）／LoveLoveLoveのせいなのよ！（ED）
0824デフォルトの名無しさん2008/10/09(木) 02:44:06
PS3とXboxとPCのクロスのUnrealエンジンは例外使ってるけどね
0825デフォルトの名無しさん2008/10/09(木) 03:38:21
同じゲームでも、もともとPC、というかWindowsメインだと例外も使ってる（こともある）
でもいまコンシューマ業界はDSとWiiが主流だからねえ……。
コンシューマ業界全体からみたら例外を使うのはレアケースになっちゃう
0826デフォルトの名無しさん2008/10/09(木) 09:01:48
要するに
D言語がVisualStudioで使えれば全ては解決する
VSで使えるのがC++しか無いから使ってるだけだろ。
0827デフォルトの名無しさん2008/10/09(木) 09:57:52
評価順序や引数展開でごちゃごちゃするのがイヤならAlgol系言語は全部ダメだな。
Lisp最強
0828デフォルトの名無しさん2008/10/09(木) 10:14:04
Lisp好きもbindやlambdaがC++0xで入るからちっとは楽しめるようになるぞ。
実用的アプリやフリーソフトを泥臭いWin32と美しい関数型プログラミングを組み
合わせて設計できるようになるのは楽しそうだ。
0829デフォルトの名無しさん2008/10/09(木) 10:32:16
>>826
Dて。どこをどう「要するに」なんだよｗ
0830デフォルトの名無しさん2008/10/09(木) 11:08:02
>>828
そんなのカオスになるだけだろ。
右結合、左結合、優先順位、左の評価次第で右を評価するかどうか決まる、などの演算子の一目見ただけではわからないルールがさらにオーバーロードされると振る舞いが変わる、などが混乱の元だというのだから、
構文解釈が一目でわからないAlgol系は全部ダメだと言ってるんだよ
0831デフォルトの名無しさん2008/10/09(木) 11:15:21
>>828
あんな汚い物でも lambda があれば良いというのは非常に C++ 的な発想ですね。
その点 Java のクロージャは分かってるなあと思うよ。シンプルで奇麗に書ける。
ゴスリングは良いバランス感覚を持ってるね。
0832デフォルトの名無しさん2008/10/09(木) 11:46:09
Lambdaが入ったらC++を本格的に使おうと思う
0833デフォルトの名無しさん2008/10/09(木) 11:52:22
>>832
lambdaなんて他の言語にフツーに搭載されてる仕様だろ？

今現在既に仕方なくC++を使わざるを得ない・使っている人が、
こんなものでもないよりはマシ、と思うかどうか、という次元の話じゃないの

lambda入ったから使ってみっかってのは正直意味不明な動機だ
0834デフォルトの名無しさん2008/10/09(木) 12:12:37
いやフリーソフトとかを作れる言語で関数型プログラミングができるのは
魅力的だなと思ったので。。
0835デフォルトの名無しさん2008/10/09(木) 12:16:31
関数型プログラミングは関数型言語でやるのが一番快適。
0836デフォルトの名無しさん2008/10/09(木) 12:21:12
いや今ﾄﾞﾄﾈﾄやってるけど実行環境とかうるさいからやっぱC++にしようと思ってる。
Haskellを勉強して関数型はおもしろいと思ったけど実アプリ開発にはやっぱ難しいと思う。
概念をC++のLambdaで生かせればいいかなと思ってる。
0837デフォルトの名無しさん2008/10/09(木) 12:46:34
Cは低級。
故に他の言語と混ぜることも困難ではない。
しかし、C++で拡張された部分はどーしようもない。
0838デフォルトの名無しさん2008/10/09(木) 12:55:55
お前がどう思おうと世の中ではふつーに使われてるからwww
0839デフォルトの名無しさん2008/10/09(木) 13:42:49
>>819
C++の例外はやめた方がいい、本物の罠だから
例外はガベージコレクタを持たせないと問題が連発してしまう。
特に operater new との組み合わせは、ひどい有様になるので・・・
&& || とは訳が違う、boostあたりでも自在に使えるC++をきわめている人間でも苦しい問題が数多くある。
0840デフォルトの名無しさん2008/10/09(木) 13:43:37
ゲームの場合 operator new をオーバーロードする事は多いと思う、だからより用心すべき。
0841デフォルトの名無しさん2008/10/09(木) 15:16:08
>839
kwsk
0842デフォルトの名無しさん2008/10/09(木) 18:10:37
そんなどうでもいいような重箱の隅つつく話よりも、C++の++のほうが問題
大きいんじゃないか？
なんて呼べばいいのかわからんだろ。
0843デフォルトの名無しさん2008/10/09(木) 18:14:56
ぷ～らぷら
0844デフォルトの名無しさん2008/10/09(木) 19:51:54
ようするに

operator && || が本物と同じ動きにすればよかっただけだろ？
0845デフォルトの名無しさん2008/10/09(木) 20:40:48
C++はC言語に比べてエラーを無視するプログラマが増えた、と思う
0846デフォルトの名無しさん2008/10/09(木) 21:03:36
意味わかんねぇ
エラーってコンパイルエラーか？
どうやって無視するんだそれ
0847デフォルトの名無しさん2008/10/09(木) 21:12:35
戻り値無視だろjk
0848デフォルトの名無しさん2008/10/09(木) 21:13:05
exceptionとerrorの違いがわからないプログラマが増えた、と思う
0849デフォルトの名無しさん2008/10/09(木) 21:30:12
>>844
できるわけねーだろ、タコ
0850デフォルトの名無しさん2008/10/09(木) 21:51:46
律儀にstd::bad_allocなんて拾ってられませんよねー
0851デフォルトの名無しさん2008/10/09(木) 22:17:28
>>849

本物の && ||がしてる方法をそのまま使えばいいんだが
できるわけねーなら本物もできるわけねー
0852デフォルトの名無しさん2008/10/09(木) 22:21:09
>>850
拾えばいいじゃない。

スマートポインタを使わないとメモリリークするからガベコレないと例外使えないと逝ってるんじゃねーの。
俺はそれよりも、try中でスコープ切られてるから、オブジェクトを作ってから死ぬまでtry中に書かねばいかんのがうざいね。
0853デフォルトの名無しさん2008/10/09(木) 22:22:42
>>851
できるわけねーだろ。
オーバーロードするのは&& ||「関数」なんだからな。
0854デフォルトの名無しさん2008/10/09(木) 22:23:35
メモリが足りないなんていう非常事態で
例外みたいな砲丸を悠長に投げられるほどコンピュータが健康だなんて状況はちょっと考えられない
拾おうが拾うまいがクラッシュするんだから別によくね
0855デフォルトの名無しさん2008/10/09(木) 22:23:52
main()
{
try
{
//uiui
}
catch(...){}
}
0856デフォルトの名無しさん2008/10/09(木) 22:24:44
>>853
関数以外で書かせりゃいいだろ
0857デフォルトの名無しさん2008/10/09(木) 22:24:48
C++がlazyとか持ってれば良かったんだけどねー
いらん機能はいっぱいあるくせにこういう肝心な機能がないのがC++
0858デフォルトの名無しさん2008/10/09(木) 22:25:37
スマポかガベコレないと、例外は使う気起きないわなぁ
0859デフォルトの名無しさん2008/10/09(木) 22:26:03
>>856
良いシンタクスの考えがあるなら是非標準化委員会に提案して下さい
0860デフォルトの名無しさん2008/10/09(木) 22:26:55
>>851
> 本物の && ||がしてる方法をそのまま
これはない
C++には実行時に式を評価する手段が無いのだから

やるなら、右オペランドを、bool値を返す関数にくるんでoperator &&に渡す
operator &&の中で右オペランドを評価したい場合はその関数を呼ぶ
そういう形になるな

が、そこまでする必要は無いだろ
.演算子のように、単に&&や||もユーザ定義できないようにすればよかっただけ
0861デフォルトの名無しさん2008/10/09(木) 22:33:47
bool operator &&(const Hoge &lhs, const Hoge &(*rhs)())
{
　return lhs & rhs();
}

解決しました^^
0862デフォルトの名無しさん2008/10/09(木) 22:35:31
<<で文字書いたりするのはどう思う？
0863デフォルトの名無しさん2008/10/09(木) 22:35:49
>>861
そうそう
つか、「bool値を返す関数」じゃなかったな、スマソ

デフォで遅延評価の機能を持たない言語での一般的なやり口だな
lambda式でくるんでやるのは
0864デフォルトの名無しさん2008/10/09(木) 22:36:51
vectorなどSTLコンテナにポインタ食わせても、死ぬとき自動で解放してくれないからな。
そのくせauto_ptrはコンテナに食わせられないし。
かといって、コンテナから派生できないから自分でデストラクタ書くわけにもいかんし、
まあ、いろんな機能を入れた割には標準の範囲内では上手く動かんのよね。
0865デフォルトの名無しさん2008/10/09(木) 22:38:20
>>832
当たり前だけど Lambda が入っただけでは関数型言語にはならないでしょ。
関数型言語が便利なのは、言語仕様や組み込みの関数やライブラリが
宣言的にプログラムを書く事を前提として作られているからであって、
Lambda があれば良いという物ではない。関数が引き数に関数を受けて
関数を戻り値として返す事が自然に出来て、副作用は奇麗に分離出来て、
末尾再帰をジャンプに置き換えてくれるから再帰的な定義も自然に書けて、
みたいなね。

関数と変数をまとめてクラスという名前にしただけではオブジェクト指向
とは言えないのと一緒。多態とか継承とかが無いとね。
0866デフォルトの名無しさん2008/10/09(木) 22:45:29
STLがいろいろと不備でそれカバーするのがboostとか言う変態ライブラリだろ
最悪じゃね？
0867デフォルトの名無しさん2008/10/09(木) 23:11:29
boostみたいなゲロの塊を
「最先端のライブラリや！」とか勘違いされると非常に困る
0868デフォルトの名無しさん2008/10/09(木) 23:48:31
つか || && ごとき現実には対応すらするかよっての
普通に作って問題発生せんわ
0869デフォルトの名無しさん2008/10/09(木) 23:52:04
>>865
中途半端に<algorithm>なんてものがあるからたちが悪い。
0870デフォルトの名無しさん2008/10/09(木) 23:55:30
>>810
つcrossnet
0871デフォルトの名無しさん2008/10/09(木) 23:58:32
>>867
バッドノウハウを作り続けているという意味で最先端ではないか。
0872デフォルトの名無しさん2008/10/09(木) 23:59:29
>>799
どうでもいい所からつつくから標準化委員会に相手にされない
重要度と優先度と危険性がごちゃまぜになってるマなんか笑われても仕方ない
0873デフォルトの名無しさん2008/10/10(金) 00:02:06
> 重要度と優先度と危険性がごちゃまぜになってるマなんか笑われても仕方ない

些細なバグだろうとバグはバグっしょ
そんなバグどうでもいいよ、とかお前さん
バグレポ出してきた客に言うの？
0874デフォルトの名無しさん2008/10/10(金) 00:05:41
>872
なんでいまさら終わった話題に、しかも斜め上のレスしてるの？
0875デフォルトの名無しさん2008/10/10(金) 00:16:23
それは872自身が重要度と優先度と危険性がごちゃまぜになってるマだからだよ
0876デフォルトの名無しさん2008/10/10(金) 00:17:02
&& || の問題など
e = a*b+c*d;
についてオプティマイズでa*bが先に計算されるかc*dが先に計算されるか分からなくて不明だから、問題だといっているような物だ。
ただのアホ
0877デフォルトの名無しさん2008/10/10(金) 00:19:33
>>874
ということにしたい気持ちはよくわかる
0878デフォルトの名無しさん2008/10/10(金) 00:20:49
オプティマイズの話よりセマンティクスの話の方が、よりクリティカルだと思うけど。
優先度ってそういう事だろ。
0879デフォルトの名無しさん2008/10/10(金) 00:22:03
オイオイ、また同じ話を繰り返すのか？
>>799と前後の流れを100回読み直せ
マジで理解できないなら相当頭悪いよ
0880デフォルトの名無しさん2008/10/10(金) 00:22:17
で、例外の話にはつっこまないのな。
0881デフォルトの名無しさん2008/10/10(金) 00:23:53
i++ && j++

&&の振る舞いが異なるのが最適化の誤差程度ですか、そうですか。
0882デフォルトの名無しさん2008/10/10(金) 00:26:51
open("hoge") or die;
とかPerlでよく書くけど、orの意味変わったらどうなると思ってるんだよ
0883デフォルトの名無しさん2008/10/10(金) 00:27:04
>>873
それ前提が間違ってるから
意図的にバグ埋め込むテロリストみたいな奴にコード書かせる奴のほうが悪い
そんな危険な奴相手なら書かせないかけコードレビューをきっちりするか
コード検証ツールで定期的に確認するか
或いはさっさとクビにするか。

意図せずに埋め込むなんざありえんよ
0884デフォルトの名無しさん2008/10/10(金) 00:27:31
1ステートメントに++が2回出てきてる時点で論外ですわ
++、--、=ファミリーは1行に1個まで、守らないと鼻から悪魔よー
0885デフォルトの名無しさん2008/10/10(金) 00:28:53
>>883
脆弱性がバグではないと言い張れたら
MSもこんなにセキュリティパッチを連発する必要無いんだけどね
0886デフォルトの名無しさん2008/10/10(金) 00:29:00
>>882
operatororとかないから
てかC++の話だから、グロスクリプト言語はお引き取り下さい
0887デフォルトの名無しさん2008/10/10(金) 00:29:04
振る舞いが違っていても問題ないようにコード書くよう教育されているだろ、普通。
カッコつけろ、いったん変数に入れろ、こんなの基本。
0888デフォルトの名無しさん2008/10/10(金) 00:29:49
>>886
C++でもPerlと全く同じことなのだが
理解できていないようですね
0889デフォルトの名無しさん2008/10/10(金) 00:30:36
アンチは危険性の指摘云々じゃなく自分の好きな話がしたいだけだろ
C++で開発したこと無いんじゃないかってくらい、現実を見てない指摘

もっと危なくて新人ならよくやるポカが沢山あるのに。
0890デフォルトの名無しさん2008/10/10(金) 00:30:53
>>884
副作用のある物を演算子ののオペランドにしたらどうなるという広い課題に対して、
挙げた一例に対する煽りしかできない時点でバカを自白しているようなもんだ。
0891デフォルトの名無しさん2008/10/10(金) 00:31:24
まさか
check(x) && exit(1);
とか書いてる奴がいるの？

そんな奴はプログラマやめて下さい
0892デフォルトの名無しさん2008/10/10(金) 00:32:01
C++は本当に大問題ありだが、こんな批判がでるとC++が無問題のように見えてしまうから大問題だ。
0893デフォルトの名無しさん2008/10/10(金) 00:32:08
>>884
881のことならその点は問題ないだろ。
iとjが実体は同じ、例えばint& i = j;とでもしているのでない限り。
0894デフォルトの名無しさん2008/10/10(金) 00:32:16
>>889
で、例外機能についてはどう思う？
0895デフォルトの名無しさん2008/10/10(金) 00:33:14
>>891
仕事ではやらないので勘弁してください。
0896デフォルトの名無しさん2008/10/10(金) 00:33:38
>>891
while ((c = getchar()) != EOF && c != '\n')....
とか普通にかけるでしょ

何のために「わざわざ」&&や||が副作用完了点とされ、
評価順序が厳密に仕様で定義されてると思ってるのかしら
0897デフォルトの名無しさん2008/10/10(金) 00:35:06
>>896
ヤメロぼけかす死ね
優先順位で副作用作るな
0898デフォルトの名無しさん2008/10/10(金) 00:36:08
>>897
優先順位？

馬鹿確定
仕様理解してないだろ
0899デフォルトの名無しさん2008/10/10(金) 00:36:21
>>887
(軽い判定) && （重い判定)
でもいったん代入するんですか。
(副作用のない判定) && (副作用の出る関数の辺値）
もいったん代入するんですね。
0900デフォルトの名無しさん2008/10/10(金) 00:37:57
while (true)
{
　c = getchar();
if( c != EOF && c != '\n')....
}

こうかけ、非常識なコード書くな
0901デフォルトの名無しさん2008/10/10(金) 00:38:52
perlでは短絡を使うが、それ以外では短絡を使わないな。
0902デフォルトの名無しさん2008/10/10(金) 00:39:13
なるほど、K&Rや禿は非常識なんだな
0903デフォルトの名無しさん2008/10/10(金) 00:39:31
>>896
そんなふざけたコード書いて悦に入ってる輩のせいで
真似してカオス文書くアホが後を絶たないんだ
やめてくれよ

while(1)
{
　c = getchar();
　if(c == EOF || c== '\n')
　{
　　break;
　}
　...
}
0904デフォルトの名無しさん2008/10/10(金) 00:40:29
テキストの1バイトも無駄に出来なかったK&Rの時代のバッドノウハウを
ギガバイト時代に持ち込まないで下さい
本当にやめて下さい
0905デフォルトの名無しさん2008/10/10(金) 00:41:53
>>904
お前がバットノウハウだ
お前が死ね、今でもこの手の基本は流石に変わらんわボケ
0906デフォルトの名無しさん2008/10/10(金) 00:42:22
話は逸れるが、個人的にはこういう風に書けるのが好き。
while (get(&c)) //結果はcに入る。EOFなら偽を返す。
0907デフォルトの名無しさん2008/10/10(金) 00:43:28
>>906
そこまでならば許容だが・・・
0908デフォルトの名無しさん2008/10/10(金) 00:44:28
>>899
そんなに重いんだったらこうだな
if(軽い判定){
　if(重い判定){
　　...
　}
}
もしくはこう
if(軽い判定){
　return;
}
if(重い判定){
　...
}

&&よりよっぽど明確
0909デフォルトの名無しさん2008/10/10(金) 00:45:51
まぁ異常なコードを書けば些細な問題が表面化するのも仕方がないというか・・・ヤメロあほたれ
0910デフォルトの名無しさん2008/10/10(金) 00:46:45
C++信者大好きなboostで&&が使われてるかどうか見てみたら？

&&は非常識、なんでしょ
0911デフォルトの名無しさん2008/10/10(金) 00:46:55
>>905
うるせえよ化石
896の利点は何だ？
読みやすい？お前だけだ
速い？コンパイラの最適化なめんな

いい加減に馬鹿げた短縮構文なんか捨てろよ
何で一行にグチャグチャ押し込めなきゃならないんだよ
0912デフォルトの名無しさん2008/10/10(金) 00:50:05
>>910
分かっていて使うやつらはちゃんと把握してコードされてるだろ、使う側が適当でも問題でないようになってるから。
0913デフォルトの名無しさん2008/10/10(金) 00:50:15
getcharとwhileは100歩譲ってまだ分からなくもないとしよう。
だが、ifでやる奴は本当消えてほしい、無論C++に限らない。
hoge_type x;
if ((x = get_hoge()) != xxx)
0914デフォルトの名無しさん2008/10/10(金) 00:51:21
逆にコンパイラが遅いとか言ってるのは、おまいのマシンが時代遅れなだけじゃないのかとｗ
0915デフォルトの名無しさん2008/10/10(金) 00:52:01
C++ のコンパイラは遅いよ。言語仕様がそうさせてるから仕方が無い。
0916デフォルトの名無しさん2008/10/10(金) 00:52:35
while(*dst++ = *src++);みたいなのを
「大事なテクニックだからしっかり覚えるべき」みたいに書いてるK&Rは
禁書に指定すべき

こんなものがバイブルになってるからCとその子孫はいつまでもダメなんだ
0917デフォルトの名無しさん2008/10/10(金) 00:52:40
boostといえば、スマートポインタの代入等で発生する回避しがたい例外の問題についてswapを使って例外の問題を封じ込める所とか衝撃だったな
普通の人は気付かない問題もこれを使えば表面化しない。
0918デフォルトの名無しさん2008/10/10(金) 00:53:24
ソースなんて当然人も読み書きするものなのに
計算機ですらあんなにコンパイルに時間がかかる仕様でいいのか、
という当然の疑問は持ってしかるべきだと思うんだけどね
0919デフォルトの名無しさん2008/10/10(金) 00:55:49
C++ 以外を無視すれば、コンパイルが遅い事なんて気にならない。
C++ が使えないなら幾ら早くなっても意味無いよ。
0920デフォルトの名無しさん2008/10/10(金) 00:58:21
ダメだこいつ早く何とかしないと
0921デフォルトの名無しさん2008/10/10(金) 00:59:10
>>919が哀れに思える。

>>917
代入演算子でswap使う話はExceptional C++にも解説されている。
0922デフォルトの名無しさん2008/10/10(金) 01:00:23
で、この低レベルなグダグダ議論はいつになったら終わるんだ？

脚からバグについてつつかれても
そんなのお前しか使わないよバーカバーカとか言って済むとでも
思っているのだろうか

>>885に関しても完全にスルーだね
C++信者はどうもパラレルワードに生きているらしい
0923デフォルトの名無しさん2008/10/10(金) 01:01:06
まともにレスすると負けるから荒らしに切り替えたんでしょ
とりあえずsageろよ
0924デフォルトの名無しさん2008/10/10(金) 01:01:17
>>921
逆にこれを見たとき、C++で例外は使っちゃだめなんだと確信したけどね。
ここまでやらないとバグが潜伏するんだと・・・
0925デフォルトの名無しさん2008/10/10(金) 01:04:12
パッケージソフトでも C++ で書かれているのはそこそこあると思うけど、
例外を使ってるソフトって無いの?
0926デフォルトの名無しさん2008/10/10(金) 01:10:29
あるだろうけど、だから何？
0927デフォルトの名無しさん2008/10/10(金) 01:10:50
質の高いソフトは注意深くしっかり使ってるか、使わないことを徹底してるかだろうけど
世の中の大半は中途半端に使ってて、そしてご存じの通り質が低い
使うにしろ排除するにしろ、しっかりやるとなるとコスト半端ないから
0928デフォルトの名無しさん2008/10/10(金) 01:18:52
俺はthrowしないとかは勝手なんだが、newもキャストもthrowしてくんだからしっかり
対応はしとけよ。
俺は例外使わないとか馬鹿ルール勝手に設けてリークしまくりのコード書くバカは
マジで困るよ。
0929デフォルトの名無しさん2008/10/10(金) 01:22:06
ガベージコレクタをサポートしない言語で例外を取り扱うのは非現実的だよ、どんなに注意深く作っても漏れがでる。
なぜならキャッチして自分の把握している範囲だけをdeleteすればメモリーリークを回避できるというものではないから。
0930デフォルトの名無しさん2008/10/10(金) 01:24:34
>>922
上のほうにそういう話あったじゃない。
スルーは図星の証。
もっとそういう息の根を止められるような話が欲しい。

>>929
それだけだと、スマートポインタがどうのとかって言われるぞ。

0931デフォルトの名無しさん2008/10/10(金) 01:25:39
>>930
例外導入するなら例外安全なスマートポインタの採用は不可避かと
0932デフォルトの名無しさん2008/10/10(金) 01:25:47
GCをでっかいスマートポインタの塊だと思ってる人たちに何を言っても無駄
0933デフォルトの名無しさん2008/10/10(金) 01:26:24
>>928
うちのC++大好きな部下（not新人）とかまさにそんな感じ
正味の話、教育コストは高すぎだな
0934デフォルトの名無しさん2008/10/10(金) 01:27:44
キャストが例外投げるのは知らない奴多いよな
0935デフォルトの名無しさん2008/10/10(金) 01:28:49
おれは理解すれば理解するほど、教育でなんとかなるような問題ではないと思うよ > 例外
分かっていても、なんだかの自動サポート無しでは無理だ
0936デフォルトの名無しさん2008/10/10(金) 01:34:43
デストラクタのない言語のほうが例外は面倒じゃないか？
0937デフォルトの名無しさん2008/10/10(金) 01:36:36
>>936
メモリ以外のリソースの扱いは比較的局所化しやすいけど
メモリはまず無理だよね
0938デフォルトの名無しさん2008/10/10(金) 01:38:53
だから両方が必要なんだよな

片方ずつしかないC++とJavaは両方ともダメだ
0939デフォルトの名無しさん2008/10/10(金) 01:39:22
少なくともnew/castなど言語レベルで出してくるもの、STL/boostや利用ライブラリがthrow
してくる例外にはリソース管理(shared_ptr/auto_lockなど)もしくは、catchしてリソース解放など
適切な処理をすることは絶対の義務。これができてないコードは完全なバグ。
その上で、自分の関数を戻り値返しにするかthrowで例外モデルにするかはポリシーの問題。
0940デフォルトの名無しさん2008/10/10(金) 01:42:48
>>939
みんながそうやってくれないのが最大な問題なんだよorz
0941デフォルトの名無しさん2008/10/10(金) 01:43:56
そういう話になるとRAIIがよく登場するが
RAIIもうちじゃ使い物にならん、ほぼ却下してる
そんなわけでアホみたいにtry~catch、逆に開発効率悪い罠
0942デフォルトの名無しさん2008/10/10(金) 01:44:46
new(std::nothrow)とか全員に律儀に書かせろという方が無茶な話なんだよな
現実的に考えて
0943デフォルトの名無しさん2008/10/10(金) 01:48:17
>>942
それはそれでNULLチェックしないっていうオチなんだよな
聖典D&Eにも、ぼんくらな平均的プログラマは絶対NULLチェックやらないから
そこんとこ対処しないとって話がある。まだnewハンドラの時代のことだけど。
0944デフォルトの名無しさん2008/10/10(金) 01:48:45
メモリ管理はスレッド化すれば無問題。
0945デフォルトの名無しさん2008/10/10(金) 01:50:53
RAIIはロックとかソケットとかファイルハンドルとかの管理にはすごく便利だけど
メモリの管理まで任せらせるようなものじゃない

メモリとそれ以外の共有リソースって本質的に違うよな
C++もJavaも（方向は正反対だけど）一緒くたに扱おうとしちゃってるあたりは同じ穴のムジナ
0946デフォルトの名無しさん2008/10/10(金) 01:51:23
mallocでちゃんとnullチェックする子もなぜかnewは何もしない不思議だがよくある
0947デフォルトの名無しさん2008/10/10(金) 01:54:43
その子は正しい
0948デフォルトの名無しさん2008/10/10(金) 01:56:34
>>947
いやいや上層部でのcatchすらしないってことでしょ、おそらく。
0949デフォルトの名無しさん2008/10/10(金) 01:58:06
例外版newにせっせとNULLチェック付けてやり遂げたような顔してる奴よりはまし
0950デフォルトの名無しさん2008/10/10(金) 01:59:23
次スレ代わりに似たようなテーマのスレ

C++は難しすぎ 難易度:4
http://pc11.2ch.net/test/read.cgi/tech/1221557484/l50
0951デフォルトの名無しさん2008/10/10(金) 02:00:31
mainの最上位で
catch(bad_alloc){ メモリが足りません。exit }
ってのも男らしくていいと思うぞ。
0952デフォルトの名無しさん2008/10/10(金) 02:05:53
まぁ、このスレは板にしては何だかんだ言っても盛り上がったなｗ
0953デフォルトの名無しさん2008/10/10(金) 02:08:19
>>951
個人的ツールならいつもそれ
0954デフォルトの名無しさん2008/10/10(金) 02:21:52
やっぱC++が主要な言語である割には、難解すぎたり問題点が多いから、
議論が絶えないんだろうな。
939のレベルで皆が理解してたとしてもまだRAIIとかその例外中立をどう保つのかの
ポリシー決めとか、実際にすべてのコードをそういう状態に保ち続けられるのかとかの
困難さも残るしな。

そういう困難さを解決したはずのJavaは、その代償のガベージコレクションの動作速度で
別の問題を抱えてC++を駆逐したとは言い難いし、それをさらに改良してヒープとスタックを
選んで作れるようにしたC#もまだ主流とは言い難いし、いったいなにが正解なんだろうな。
0955デフォルトの名無しさん2008/10/10(金) 02:23:19
その辺でDには期待してた
期待してたんだ

悲しいよ
0956デフォルトの名無しさん2008/10/10(金) 02:24:23
>>885
日本語でおk
全く噛み合ってないわお前のレス
0957デフォルトの名無しさん2008/10/10(金) 02:26:03
>>954-955
それと、C++0xはさらに肥大化の方向ということも追加。
Committee Draftまだ見ていないけど。
0958デフォルトの名無しさん2008/10/10(金) 02:37:07
GCマンセーもRAIIマンセーも間違いで、どっちも必要なんだよな
細かい所はGCに任せて安全性を確保するのも大事
肝心な所はプログラマが寿命をしっかり管理できるようにするのも大事
DとかC#とかはどっちも出来るようになってるし

だからC++0xがGC対応しないことには失望した
0959デフォルトの名無しさん2008/10/10(金) 02:42:11
実にその通りだが、どっちか一つ選べって言われたらGCなんだよな
局所性のあるリソース管理はまだしもフォローしやすいが
メモリだけはどうしようもない
0960デフォルトの名無しさん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;
}
0961デフォルトの名無しさん2008/10/10(金) 02:47:19
組み込みのARMやPPC, DSP好きのオレ様はGCは全く許容できない
0962デフォルトの名無しさん2008/10/10(金) 02:47:32
hello worldをcerrに送るのはおかしいだろｗｗｗｗ
0963デフォルトの名無しさん2008/10/10(金) 02:55:07
>>958
1xとか2xに入るんじゃないかｗ
0964デフォルトの名無しさん2008/10/10(金) 02:57:44
C++/CLIのハンドル取り込んじゃえばいいのに…
0965デフォルトの名無しさん2008/10/10(金) 02:58:54
C++が対象にしようとしているドメインが広すぎて結局どっちつかずなんだよ

GCなしなら最初から例外もなしで、Cよりは便利なADTやクラスが使える、ぐらいの
言語のほうがナンボかすっきりする
デフォルト引数なんてのもいらんだろ

もっと高級なものを志向するんなら、それなりの道具立てをそろえなきゃダメだ
0966デフォルトの名無しさん2008/10/10(金) 02:59:36
>>945
すまないがうちでそれやったら全部直させる
例にあがってるファイルなりソケットなりはクローズでエラーを返す可能性があるからダメ
そもそも昔のドキュメントには終了処理時にエラーの可能性がある場合はRAIIは適用外だってちゃんと書いてあったんだがなあ
いつのまにか戻り値無視する素人が増えてしまった
0967デフォルトの名無しさん2008/10/10(金) 02:59:54
cerrは凡ミスだな
しかし、言わんとすることは分かるだろ

C++言語の最初のレッスンでは、
「プログラムに書いた指示は意図通り処理されないことがある。
だから必ず失敗を恐れ、EXIT_FAILUREを返しなさい。
決してcatchを省略してはなりません。例外仕様を決めずに
コーディングを開始してはいけません。」と叩きこむ。これでOK。
0968デフォルトの名無しさん2008/10/10(金) 03:04:30
>>966
どっかで、デストラクタとclose（メンバ関数）の両方用意するのがいいって話を見たことがある。
無視していいときはデストラクタに任せ、戻り値が欲しければメンバ関数を明示的に呼ぶと言う具合。
0969デフォルトの名無しさん2008/10/10(金) 03:05:15
>>950
そのスレタイだと絶対荒れるw

まあこのスレでもなんでC++が肥大化したかはわからなかったが
信者の頭がおかしいことは分かった
0970デフォルトの名無しさん2008/10/10(金) 03:06:53
肥大化したのは単に禿が決めたことだから
一介の利用者がワーワー言った所で理解が及ぶべくもない
0971デフォルトの名無しさん2008/10/10(金) 03:12:52
もう1000ですね
間が空くたびに煽った甲斐がありました
擁護派の人たちは見てて楽しかったです＾＾
0972デフォルトの名無しさん2008/10/10(金) 03:16:49
>>969
事実そうなったからこそ、パート4まで続いている。
0973デフォルトの名無しさん2008/10/10(金) 03:24:53
>>971
埋め立てご苦労
0974デフォルトの名無しさん2008/10/10(金) 03:54:11
まぁ、世の中が本当に頭の良い奴ばっかりなら、C++以上の言語が作られそれが世界を席巻していたであろうｗ
0975デフォルトの名無しさん2008/10/10(金) 03:58:58
と、馬鹿が不毛な事を言っております
0976デフォルトの名無しさん2008/10/10(金) 07:00:20
どんなに彼が頑張っても && || が問題などという話はないという結論で
0977デフォルトの名無しさん2008/10/10(金) 08:32:04
>>976
>>799と前後の流れを10億回読み直せ
読み終わるまでメシも食うな
0978デフォルトの名無しさん2008/10/10(金) 08:59:04
なぜ799はこんなに必死なのか
0979デフォルトの名無しさん2008/10/10(金) 09:03:41
どっちもどっち
0980デフォルトの名無しさん2008/10/10(金) 09:15:35
【信者】C++の問題点【アンチ】
http://pc11.2ch.net/test/read.cgi/tech/1223597633/
0981デフォルトの名無しさん2008/10/10(金) 09:17:26
直球なタイトルだなｗ
0982デフォルトの名無しさん2008/10/10(金) 09:23:25
え、なに？スレ立てたの？馬鹿なの？
0983デフォルトの名無しさん2008/10/10(金) 09:31:21
便利そうだと思って拡張したらトラップだった
ってのがC++に多くて（例外なども）、その一例が&&であり、そこをピンポイントで養護しても意味をなさないっつーことでしょ。
言語としての整合性を考えて拡張しろと。
まあ、今更なんだけどね。
一旦なされた拡張が次で消えるとも思えない。
0984デフォルトの名無しさん2008/10/10(金) 09:35:58
あなたは○×言語の問題点を指摘されました
１）「おまえは○×言語もわからない馬鹿だから問題じゃない！」とレッテルを貼る
２）「その問題は俺は回避できるから問題じゃない！」と論点を摩り替える
３）「△□言語にも同じ問題があるから問題じゃない！」と論点を摩り替える
４）「～～という理由でそれは問題とは言えないのではないか？」と論理的に問題無いことを証明する
５）「確かにそこには問題があるね」と素直に認める
普通は４か５を選ぶと思うんだが、何故か１２３ばっかりだったね
0985デフォルトの名無しさん2008/10/10(金) 09:39:01
詭弁連レス…
0986デフォルトの名無しさん2008/10/10(金) 10:05:25
>>984
いやいや、&&は「普通使わないという理由でそれは問題とは言えないのではないか？」だったはず。
ちっとも論理的ではないが。
0987デフォルトの名無しさん2008/10/10(金) 10:25:18
まぁ信者は問題点に納得した時点で沈黙するからなぁ
結局新規の馬鹿信者が斜め上発言してアンチがフルボッコにするループはいくらでも続く

>>986
それ論点のすり替えに該当してるからｗ
証明というなら、そう在るべき理由とその重みを挙げるべき
0988デフォルトの名無しさん2008/10/10(金) 10:26:17
&&批判に反発してた連中は、終わった話を何度も蒸し返して
無駄に傷口広げてる感じだったな

しかも禿の仕様ミスであること自体は認めているから
まともに・論理的には反論できずに
そんなのは些細なことで問題にするほうがおかしいとか
斜め上の話ばかりになる
0989デフォルトの名無しさん2008/10/10(金) 10:31:40
信者とか擁護派とかアンチとか煽りはフィルターして読むと、自分にとってはなかなか実の
ある内容だった。
非常に気を付けて使う必要があるが、気を付ければ高い性能を得ることができることが
わかった。赤兎馬みたいなもんすね。
0990デフォルトの名無しさん2008/10/10(金) 10:35:32
ていうか、&& 批判を批判しているのはC++信者ですならないんですがw
0991デフォルトの名無しさん2008/10/10(金) 10:38:08
>>989
そんなプログラミングの勉強初めて1ヶ月経ちました！見たいな事言わんでもｗ
0992デフォルトの名無しさん2008/10/10(金) 10:39:43
仮に読むまで評価しない式の参照型を追加したらもっと凄い事になりそうだ
0993デフォルトの名無しさん2008/10/10(金) 10:57:01
初心忘るるべからず
0994デフォルトの名無しさん2008/10/10(金) 11:02:32
子供の発見には、満面の笑みで「へぇ！すごいねぇ！」って言ってあげるべきだったな

>>989
素晴しい着眼点だと思うよ！今後もがんばって研鑽してね！
0995デフォルトの名無しさん2008/10/10(金) 11:06:42
満面の笑みと言うなら

>>989
素晴しい着眼点だと思うよｗｗｗｗｗｗｗ今後もがんばって研鑽してねｗｗｗｗｗｗｗ
0996デフォルトの名無しさん2008/10/10(金) 11:06:50
あんま煽ってやるなよｗ

それと、赤兎馬の比喩に適切なのはどっちかっつうとCだな
0997デフォルトの名無しさん2008/10/10(金) 11:15:06
>>994=995
必死すぎのアンチにﾜﾗﾀ
0998デフォルトの名無しさん2008/10/10(金) 11:17:00
いや、つまんないから
0999デフォルトの名無しさん2008/10/10(金) 11:23:08
つまり、
1000デフォルトの名無しさん2008/10/10(金) 11:23:50
C++最強。以上。
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。