08/10/10 09:13:53
C++の問題点について語るスレです
C++ってなんであんなに肥大化しちゃったの？
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
08/10/10 11:05:40
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
3:デフォルトの名無しさん
08/10/10 13:14:50
だからー いちいち禁止しなくても
本物の || && とおんなじ方法で動くようにすればいいだけだろ
4:デフォルトの名無しさん
08/10/10 18:04:14
&&のオーバーロードなんてgotoやlongjmpみたいなもの
使う方が悪い
5:デフォルトの名無しさん
08/10/10 19:05:52
もう飽きた、他のネタ頼むわ
6:デフォルトの名無しさん
08/10/10 19:26:39
そうだな
function-try-blockの話でもしようか
7:デフォルトの名無しさん
08/10/10 20:39:02
ライバルが現れた
gcjって使ってる人います？
ｽﾚﾘﾝｸ(tech板)
8:デフォルトの名無しさん
08/10/10 20:44:16
URLﾘﾝｸ(shootout.alioth.debian.org)
見ると、ATSって言語が異常に速いんだが
誰か使ってる人いる？
9:デフォルトの名無しさん
08/10/11 11:16:32
|| && 問題なんて「過去との互換性をとるために保守してあるだけで、現在は使わないでください」的なものだろ
Javaだって「将来無くすことになったので、このメソッドは使わないで新しいの使ってね」って言うじゃん。
で、実際に無くすか、互換性のために残しておくか。
どっちが正しいかは白黒なんてつかん
10:デフォルトの名無しさん
08/10/11 11:39:04
なんだこの頭の悪いレスは
アンチのなりすましですか？
11:デフォルトの名無しさん
08/10/11 19:26:07
ウドンズのCreateWindowみたいなものか
12:デフォルトの名無しさん
08/10/11 20:36:58
CreateWindowはObsoleteじゃないだろ
13:デフォルトの名無しさん
08/10/11 23:59:55
C++に限らずif (x) if (y)のシンタックスシュガーとして&&は時々便利に感じる。
14:デフォルトの名無しさん
08/10/12 04:15:14
アイちゃんちょっと頑張り過ぎじゃね？
15:デフォルトの名無しさん
08/10/12 04:58:04
>>13
時々じゃなくてそれに基づいてプログラムを書いてるわけだが
お陰でオーバーロード時に問題が生じてしまったのは禿の責任ではない
16:デフォルトの名無しさん
08/10/12 20:00:28
&& や || をオーバーロードなんてすんなってこった。
17:デフォルトの名無しさん
08/10/12 21:43:39
正しい動作するようにかける方法を
関数以外で提供すれば言いだけ
18:デフォルトの名無しさん
08/10/12 22:52:55
正しいも動作も何も、&&, ||が論理演算である必要すらないのだが。
+を掛け算、*を足し算にして、足し算優先な数式すらつくれるというのに。
19:デフォルトの名無しさん
08/10/12 23:19:21
それはAdd()という名の引き算関数作ることと何が違うの？
20:デフォルトの名無しさん
08/10/13 00:02:32
指数演算ならMul()という名前の足し算関数はありうる
21:デフォルトの名無しさん
08/10/13 00:06:49
>>19
汗の世界では良くあること。
22:デフォルトの名無しさん
08/10/13 00:26:54
>>19
全然違うぜ。
Add(Mul(1, 2), 3)
はあくまでmulを解釈した後addを解釈するし
Mul(Add(1,2), 3)
はAddを先に解釈する
1+2*3
は
1*2+3
としたところで、必ず*が先に解釈される。
プログラムの書き手が解釈順位を決めるのが関数
演算子はコンパイラがすでに解釈順位を決めている。
23:デフォルトの名無しさん
08/10/13 00:31:04
演算子はコンパイラがすでに解釈順位を決めている。
にらそれと同じことをすればいい
24:デフォルトの名無しさん
08/10/13 00:31:53
>>23
まあ、俺もうまく説明できてないが、
問題点を理解できてないのに噛み付かなくてもいいよ。
25:デフォルトの名無しさん
08/10/13 02:18:29
>>24
で、そういうことをするプログラマーが問題ではないと
26:デフォルトの名無しさん
08/10/13 11:11:10
自由と責任は表裏一体。
低レベルの開発ならC並の何でもできる自由度が必要だけど、アプリよりになればなるほど勝手な振る舞いはしてほしくない。
今はハードをベタベタに触る言語とGUIやwebをらくらく使う言語と使い分ける時代じゃねーのかね。
C++は全部やろうとして、肥大化してるし、トラップも増えている感じ。
何でもできるけど、責任はプログラマ側ねという言語は必要だけどすべての分野で使うべきかどうかは疑問だね。
27:デフォルトの名無しさん
08/10/13 12:30:57
本当に自由な言語には使わない自由もあるだろ。
そもそもC++をすべての分野で使うべきなんて誰も言ってないのに勝手に勘違いして
GCを全否定したり無駄な継承したりするのが義務だと思い込んでるだけ。
28:デフォルトの名無しさん
08/10/13 12:33:54
分かってる人は分かった上でC++使ってればいいんだよ。
分からない人が「たくさん」いる現場で使うにはC++はしんどい言語だってこと。
29:デフォルトの名無しさん
08/10/13 12:33:56
流れを読まずにかきこ
GCって何？
30:デフォルトの名無しさん
08/10/13 12:35:07
分かってないのに分かった気になってる人がたくさんいる言語
31:デフォルトの名無しさん
08/10/13 12:36:31
Graphics Context
Grand Central
Gabage Collection
32:デフォルトの名無しさん
08/10/13 13:40:52
nintendo
33:デフォルトの名無しさん
08/10/13 15:39:46
前スレ984、少し改変
あなたは○×言語の問題点を指摘されました
１）「おまえは○×言語もわからない馬鹿だから問題じゃない！」とレッテルを貼る
２）「その問題は俺は(普通は)回避できる(使わない)から問題じゃない！」と論点を摩り替える
３）「△□言語にも同じ問題があるから問題じゃない！」と論点を摩り替える
４）「～～という理由でそれは問題とは言えないのではないか？」と論理的に問題無いことを証明する
５）「確かにそこには問題があるね」と素直に認める
34:デフォルトの名無しさん
08/10/13 16:04:48
２と４の違いはなんだ
属人性の排除とかいうやつか
35:デフォルトの名無しさん
08/10/13 16:30:24
2はオールマイティーだな
どんな言語・問題点だろうと普通は使わないからおkって答えればいい
36:デフォルトの名無しさん
08/10/13 16:36:29
包丁やナイフにも人をさせる問題があるが世界中で愛されている
37:デフォルトの名無しさん
08/10/13 17:02:14
ナイフなんかは問題が明らかになれば規制される物だよな
38:デフォルトの名無しさん
08/10/13 17:02:36
包丁やナイフは人をさせるということが予測がつくが、
C++の演算子オーバーロードや例外は想像を超えた害悪があるから問題なんでしょ。
39:デフォルトの名無しさん
08/10/13 17:03:43
つーか包丁は役に立つが
&&のオーバーロードは罠なだけで役に立たん
40:デフォルトの名無しさん
08/10/13 17:11:25
追加
６）「問題はあるけど愛されてるから無問題」と論点を摩り替える
もう何でもアリだなｗｗｗ
41:デフォルトの名無しさん
08/10/13 17:16:17
演算子のオーバーロードは無いと困る機能でもないのに
問題を孕んでるのが嫌らしいよな。結局、無い方がいい。
42:デフォルトの名無しさん
08/10/13 17:27:27
>>41
演算子のオーバーロードは無いと困るだろう
43:デフォルトの名無しさん
08/10/13 17:28:40
演算子オーバーロード全部がまずいのではない
&& || ,
がまずいだけだ
さしあたりはな
44:デフォルトの名無しさん
08/10/13 17:31:09
()、->、newなんかは大活躍ですよ
45:デフォルトの名無しさん
08/10/13 17:31:25
>>40
論点うんぬんは関係ない
ただ根拠がいい加減なだけ
46:デフォルトの名無しさん
08/10/13 17:36:35
operator++()の引数はいらない子
47:デフォルトの名無しさん
08/10/13 17:39:00
>>44
ユーザ定義の演算子を作らなくても実現出来ると思うんだけど
48:デフォルトの名無しさん
08/10/13 18:07:22
そりゃそうだ。どれも関数呼び出しに還元できる。
それ言ったらどの演算子も多重定義できる必要は無い。
複素数やベクトルでa + bと書きたいのと同じようにスマートポインタではp->mと書きたい。
49:デフォルトの名無しさん
08/10/13 18:41:28
屋上屋ってやつか
50:デフォルトの名無しさん
08/10/13 18:51:31
operator->は生ポインタを隠すのに有効
と思ってたけどp.operator->()って普通に出来ちゃうのな
あまり意味がないような気がしてきた
51:デフォルトの名無しさん
08/10/13 19:25:06
あまり意味がないことを悟った上で使えってことじゃね
52:デフォルトの名無しさん
08/10/13 20:33:58
覚えたての厨房が粋がってトリッキーなオーバーロードをしないように気をつけないといけないのが面倒くさい。
53:デフォルトの名無しさん
08/10/13 20:43:27
>>50
そう、隠すためではなく糖衣構文を提供するためのもの。
54:デフォルトの名無しさん
08/10/14 05:32:02
お前らいい加減にしろよ
前スレは10年近く前のネタを1000もかけて焼き直しただけだろ
これ以上一体何を続けるつもりだ？
URLﾘﾝｸ(www.kh.rim.or.jp)
55:デフォルトの名無しさん
08/10/14 09:11:42
その偽ネタインタビューと現在のC++の問題点となんの関係がある？
56:デフォルトの名無しさん
08/10/14 09:21:25
>>55
ヒント:読んだばかり
57:デフォルトの名無しさん
08/10/14 10:41:05
>>55
え？ネタって書いてあるのが読めなかったの？
え？書いてある内容がどんなもんかすらわからなかったの？
え？もしかしてニホンゴワカラナイ？
58:デフォルトの名無しさん
08/10/14 11:14:57
>>57
日本語でおｋ
59:デフォルトの名無しさん
08/10/14 18:12:29
前スレと>>54見てこれなら、真性馬鹿はゆとりとは一味違うな
60:デフォルトの名無しさん
08/10/15 10:02:39
横だが本気で意味わからん
真正馬鹿でもゆとりでもいいから是非日本語で詳しく解説してくれ
ちなみに前スレって一言でまとめると
「斜め上発言でアンチからフルボッコされるドM信者スレ」
だよ？
61:デフォルトの名無しさん
08/10/15 18:03:39
斜め上発言で信者からも「アンチからも」フルボッコされるドMアンチもいました
62:デフォルトの名無しさん
08/10/15 18:25:37
え？そんなの覚えないけど？
すごく興味あるから印象操作じゃないならポインタ示してね
63:デフォルトの名無しさん
08/10/15 22:58:32
>>60
すごく興味あるから印象操作じゃないならポインタ示してね
64:デフォルトの名無しさん
08/10/16 10:17:02
前スレ987
>まぁ信者は問題点に納得した時点で沈黙するからなぁ
>結局新規の馬鹿信者が斜め上発言してアンチがフルボッコにするループはいくらでも続く
前スレ988
>&&批判に反発してた連中は、終わった話を何度も蒸し返して
>無駄に傷口広げてる感じだったな
>しかも禿の仕様ミスであること自体は認めているから
>まともに・論理的には反論できずに
>そんなのは些細なことで問題にするほうがおかしいとか
>斜め上の話ばかりになる
65:デフォルトの名無しさん
08/10/16 10:32:36
ところで、&&や||をオーバーロードすることの何が問題なの?
66:デフォルトの名無しさん
08/10/16 18:38:55
結論から言うと、演算子オーバーロードはＳＴＬ向けの関数オブジェクト作るためだけに使え、
ということだな。
67:デフォルトの名無しさん
08/10/16 19:47:53
, || && は boost::spirit で活躍しているよ。
68:デフォルトの名無しさん
08/10/16 21:27:42
>>66
なぜそれが結論なのかが知りたいのですけど?
一体何が問題なのですか?
69:デフォルトの名無しさん
08/10/16 22:10:53
std::cout << "banana" << count << std::endl;
(ノ ﾟДﾟ)ノ ＝＝＝＝ ┻━┻
70:デフォルトの名無しさん
08/10/16 23:04:10
コンテナ継承させてよぅ
71:デフォルトの名無しさん
08/10/16 23:24:11
ただの質問スレだったら、protected継承でいいじゃないって答えるところだな。
72:デフォルトの名無しさん
08/10/16 23:49:18
>>65
組み込み型に対する&&や||は短絡といって、
左から順に評価していって、
結果が分かったらそれ以降の評価を行わない仕組みになってる。
たとえば、
bool f1(); bool f2();
if ( f1() && f2() )
という式があったとすると、f1が偽の場合、f2は評価されないことが保証される。
しかし、&&や||のオーバーロードの場合は関数呼び出しと解釈されるため、短絡がない。
それどころか、関数呼び出し順序は標準に規定されていないため、
どちらが先に評価されるかすら分からない。
my_bool b1(); my_bool b2();
if ( b1() && b2() )
この場合、b1とb2のどちらが先に評価されるか分からない(処理系依存)。
分かりにくいバグの元になる、コードの可搬性を損なう、などの理由から
&&や||のオーバーロードは推奨されない。
73:デフォルトの名無しさん
08/10/17 00:22:41
>>72
つまり、&&オーバーロードは、+等のオーバーロードとは違う解釈で実行されるってことなの?
それなら、大きな問題だなぁ...
74:デフォルトの名無しさん
08/10/17 00:26:31
>>組み込み型に対する&&や||は短絡といって、
それと同じ構造にすればいいだろ
75:デフォルトの名無しさん
08/10/17 00:29:42
>>74
C#とかそれを目指している。
C++でもBoost.Lambdaは頑張った。
あと今から同じ構造になる仕組みをC++に持ち込んだとしても、
「互換性のため」現状の&&と||もそのまま残ること間違いない。
76:デフォルトの名無しさん
08/10/17 01:43:05
比較的どうでもいい豆知識だな
77:デフォルトの名無しさん
08/10/17 01:51:46
遅延評価の考え方がどうでもいい豆知識っすか
Cにどっぷりはまるとそうなっちゃうのね
78:デフォルトの名無しさん
08/10/17 02:33:00
短絡評価 short-circuit evaluation と遅延評価 lazy evaluation はまったくの別物だぞ
遅延評価は、必要になるまで変数の値の計算を先延ばしにするHaskellのアレだ
79:デフォルトの名無しさん
08/10/17 02:37:48
同じ様なもんだろ
右オペランドを遅延評価することを短絡評価という
80:デフォルトの名無しさん
08/10/17 02:44:31
じゃあ遅漏評価は？
81:デフォルトの名無しさん
08/10/17 03:07:21
>79
遅延評価はもっと広い意味の言葉だから混同するとややこしい。
82:デフォルトの名無しさん
08/10/17 08:55:24
>>64
何の指摘にもなってないよ
83:デフォルトの名無しさん
08/10/17 09:10:07
オーバーロード関数のDLLが・・・
84:デフォルトの名無しさん
08/10/17 09:13:17
>>83
日本語でok
85:デフォルトの名無しさん
08/10/17 10:40:56
オーバーロードしたら&&が論理和どころか論理演算ですらある必要がないので、
通常と同じ動作にしたらいいじゃんという主張は無意味だろ。
86:デフォルトの名無しさん
08/10/17 11:07:09
演算子の元の意味と大きく異なるオーバーロードは駄目だろ
おまえは+が加算である必要が無いからって乗算にするのか？
87:デフォルトの名無しさん
08/10/17 12:04:19
＞ 演算子の元の意味と大きく異なるオーバーロードは駄目だろ
そこで << ですよ
88:デフォルトの名無しさん
08/10/17 12:10:38
>>72
良く分からんが
if ( b1 && b2 )
は
if ( b1.operator&&(b2) )
と等価じゃないの?
89:デフォルトの名無しさん
08/10/17 13:09:18
常識という眼鏡で僕達の世界はのぞけやしないのさ
夢を忘れた古いプログラマーたちよ
アンドじゃないアンドじゃない
素敵な世界
90:デフォルトの名無しさん
08/10/17 15:03:38
>>88
operator&&() が my_bool のメンバならね。
でも
bool operator&&(const my_bool& a, const my_bool& b)
かも知れない。
更に、b1 が左辺値ではなく my_bool を戻す式だったとき、
やっぱり b2 とどっちが先に評価されるかは判らない。
91:デフォルトの名無しさん
08/10/17 16:06:02
>>90
引数の評価順を重要視する意味がよくわからん
引数の時点で、真偽がわかったとしても関数から抜け出す手段は無いとおもうが?
b1 && b2 && b3
の式の場合
operator&&(operator&&(b1, b2), b3)
となって、operator&&(b1, b2)が偽の場合でも、一番外側のoperator&&()が実行されるから嫌だって事なら、ちょっとだけ理解できるかもしれないが
だからと言って、C++の欠陥だと大声で言うようなものでも無いと思うのですが
92:デフォルトの名無しさん
08/10/17 16:52:03
>>91
短絡評価のメリットが解らない、ってこと？
93:デフォルトの名無しさん
08/10/17 17:17:31
>>92
短絡評価のメリットを受けられるほど長い論理式を使うつもりなのですか?
それとも、短絡評価のメリットを受けられるほどのif文の山を築く気ですか?
94:デフォルトの名無しさん
08/10/17 17:41:19
話がまた斜め上の方向に捩れてるな
>>91
if 式 文
で式の内容如何によらず文が評価されていいと思ってるのか？
遅延評価無しではif文を関数化することは出来ない
だから禿も?:はoperator化していない
にもかかわらず、同様の機能を持っている&&や||をoperator化しているのが
マヌケだという話だろ
>>93
言語仕様の問題をプログラミングスタイルの方向に摩り替えたい人発見
95:デフォルトの名無しさん
08/10/17 18:00:57
バグの原因は小さいものだから
大きな問題ではないと考えるのも無理はない
96:デフォルトの名無しさん
08/10/17 18:05:33
INT i=1,j=1; //なんかint的なクラスだと思いね
i++ || j++;
cout << i << "," << j;
||がオーバーロードされていなければ「2,1」が表示される
されていれば「2,2」が表示される
open(file) && abort();
&&がオーバーロードされていなければ、ファイルオープンに成功すれば処理が続行される
されていればファイルオープンに成功したのに異常終了する
97:デフォルトの名無しさん
08/10/17 18:32:16
>>94
論理式は論理式だろ?
if文や三項演算子とは関係ないんじゃない?
>>96
むしろ、その使い方が、言語仕様の悪用だと思います
98:デフォルトの名無しさん
08/10/17 18:46:18
>>97
いや、ショートサーキットの&&や||はifの変種みたいなもんだぞ
C/C++に引きこもっているうちは分からないかもしれないが、
他の言語もやってみれば分かるよ
99:デフォルトの名無しさん
08/10/17 18:52:24
つーか短絡評価しないなら&や|だけでいい
何のためにわざわざ&&や||が用意されてると思ってるんだ
100:デフォルトの名無しさん
08/10/17 18:54:39
>>99
それもちょっと違うけどな
1 && 2は真だけど 1 & 2は0だし
101:デフォルトの名無しさん
08/10/17 18:55:39
そうだな
ごめんアホなこと言った
102:デフォルトの名無しさん
08/10/17 19:44:48
>>98
論理式が返すのは、論理値だろ
論理式の処理過程を期待してプログラムするってのは、真値が特定の値である事を期待してプログラムするのと同じじゃん
103:デフォルトの名無しさん
08/10/17 19:50:03
>>102
そうだよ、一部ではもはやただの論理式ではなく制御構造と見なされているということ。
C++ではあまり見ないけど、PerlとかでHogeHoge or dieとか。
104:デフォルトの名無しさん
08/10/17 19:50:39
>>102
＞論理式の処理過程を期待してプログラムする
「期待」じゃなくてC/C++は「仕様で」「明確に」「わざわざ」評価順を
定義しているわけだが
&& || に関してはな
何の意味も無くそんな仕様にしてると思ってんの？
ま、&&や||は論理演算、bool代数だよな？そこはその通りだ。
フローコントロールもセマンティクスも変えちまう
オーバーロードなんてもってのほかだよな？
105:デフォルトの名無しさん
08/10/17 19:59:18
bool banana;
if(!banana)
{
// ↑気持ち悪いねこれ。
}
106:デフォルトの名無しさん
08/10/17 20:01:54
if(true != banana)
if(false == banana)
好きなほうを選べ
107:デフォルトの名無しさん
08/10/17 20:02:26
VB.NETではVBには無かった短略評価の
AndAlso OrElse という（キモい）演算子が追加されているのだが
その意味も分からないんだろうねえ
108:デフォルトの名無しさん
08/10/17 20:10:39
>>104
言ってることがわからない
&&や||をオーバーロードできるように定義しているのも「仕様」なんじゃないの?
109:デフォルトの名無しさん
08/10/17 20:12:51
>>108
だから、その仕様が不整合で良くないっつー話をしてるんだろ
言うまでも無く後から突っ込んだオーバーロードの仕様がマズい
110:デフォルトの名無しさん
08/10/17 20:19:03
&&や||をオーバーロードの場合はコンパイラが短絡すればいいだけだろ
111:デフォルトの名無しさん
08/10/17 20:27:57
何だそれ
互換性が無くなってさらにカオスになるだけじゃねえか
112:デフォルトの名無しさん
08/10/17 20:31:27
&&と||の意味がわかんねー奴はC++厨気取りたいんなら
More Effective C++ぐらい嫁
113:デフォルトの名無しさん
08/10/17 20:36:52
.front()も.begin()も同じで良いジャン
なんで違うの
114:デフォルトの名無しさん
08/10/17 20:48:12
>>113
hoge.front()は*hoge.begin()相当。
強いて言えば、beginからfrontは取り出せるが逆は一般にできないんでfrontがやや余計かな。
115:デフォルトの名無しさん
08/10/17 20:52:08
front取り忘れたのかね
116:デフォルトの名無しさん
08/10/17 21:20:33
map持っていて
<<でkeyを流し込んだら valueが返ってくるクラスはあり？
117:デフォルトの名無しさん
08/10/17 21:29:44
演算子でやる理由がわからん
118:デフォルトの名無しさん
08/10/17 21:46:28
>>116
[]演算子で標準装備してない？
まあこれはkeyを持ってなかったらvalueにはデフォルトコンストラクタで生成
した値が代入されてしまうんだけど
119:デフォルトの名無しさん
08/10/17 21:51:59
[]だとポインタのとき面倒じゃね？
120:デフォルトの名無しさん
08/10/17 21:54:05
value = (*hogemap)[key]
でおけ
121:デフォルトの名無しさん
08/10/17 21:58:28
あえて operator()
122:デフォルトの名無しさん
08/10/17 22:39:11
URLﾘﾝｸ(homepage2.nifty.com)
なんでもあり
123:デフォルトの名無しさん
08/10/17 23:04:00
>>119
いやポインタに対して使うときは全部だろ
124:デフォルトの名無しさん
08/10/18 00:55:05
C++のIDEに自動的にヘッダやnamespaceを宣言してくれる奴って何かあります？
Javaとかだと適当にクラス使ってもクラスパスから候補探してくれるのがメジャーなIDEの基本機能にある。
125:デフォルトの名無しさん
08/10/18 05:16:34
>>124
ゆとりは黙ってろよ(笑)
そんな余計な機能はIDEには要らない
126:デフォルトの名無しさん
08/10/18 05:38:24
自動的にヘッダを追加するようなIDEは怖くて使えません
127:デフォルトの名無しさん
08/10/18 13:39:49
さすが生産性の無さでユーザーがみるみる減っている言語だけはあるｗ
128:デフォルトの名無しさん
08/10/18 13:56:13
>>124
C++のヘッダのincludeは単なるプリプロセッサ命令で、やってることは
原始的なコピペ
Javaは自己記述的なjarやclassからシンボルをインポートしてるわけだ
C++でそういうことをやるのは技術的に不可能ではないだろうが
向いているとは思えんな
現代的なIDEなどが出るよりはるか以前に作られた化石言語なのだから仕方が無い
129:デフォルトの名無しさん
08/10/18 14:06:23
C++はIDEととことん相性悪いからな
まるでIDEを妨害しようとしているかのような仕様
VSやBuilderやCDTはマジ頑張ってると思うのですよ
頭が下がる
130:デフォルトの名無しさん
08/10/18 21:29:58
C++を有難がって使ってる奴なんているの？
居たとしたらちょっと馬鹿すぎる
131:デフォルトの名無しさん
08/10/18 21:38:06
文句なしの代替が無いから使っているだけだよ。
132:デフォルトの名無しさん
08/10/18 22:40:11
有難がって使うプログラミング言語なんてないだろ。
133:デフォルトの名無しさん
08/10/18 22:51:52
>>130
C#がネイティブ初めから吐いてくれたらそっちに移行したいんだが
仕方ないからC++を使ってる
つーかC#プログラマ恵まれ過ぎだろ・・・
134:デフォルトの名無しさん
08/10/18 22:53:30
C++が一番簡単だから使ってる
135:デフォルトの名無しさん
08/10/18 22:59:07
結局、
136:デフォルトの名無しさん
08/10/18 23:00:16
結局、このスレにC++信者なんて居なかったってオチか
137:デフォルトの名無しさん
08/10/19 01:23:10
>>105
↑頭悪いねこれ。
138:デフォルトの名無しさん
08/10/19 14:06:06
C++が最高だと思って使ってる奴はいないだろ。
ただ分かってない上司やクライアントがいるからC++の仕事もあるってだけだ。
本当はCで十分だったり、C#やJavaの方が効率良かったりするんだが。
139:デフォルトの名無しさん
08/10/19 14:12:04
C#やJavaをフロントエンドにして、
OS依存部分や、処理が思い部分を
C言語で書くスタイルがベストだな。
既にOracleがそうだし、CADもそういうのがある。
140:デフォルトの名無しさん
08/10/19 14:23:15
C++はプログラム初級～中級者向けのおもちゃとしてはそこそこ面白い
だが普通はすぐに暗黒面に気付いて使うのを辞めるor仕事で仕方なく使うだけだ
141:デフォルトの名無しさん
08/10/19 14:41:12
その通り過ぎて何も言えねえ…
良い代替言語があれば良いんだけどね
142:デフォルトの名無しさん
08/10/19 14:53:48
D言語がふらふらしてなければなｗ
創始者が「仕様変えるぞー」を未だに自粛しないからこまったものだ。
143:デフォルトの名無しさん
08/10/19 16:11:15
まあ暗黒面に気付かないうちはまだまだ初心者ってことだ
それに気付いた時にはバッドノウハウばかりで他言語に応用が効かないのも悔しいところだ
144:デフォルトの名無しさん
08/10/19 16:19:28
Plan9(笑)
D言語(笑)
145:デフォルトの名無しさん
08/10/19 16:37:25
バッドノウハウを追求するのは楽しい
しかしチームでやる仕事ではゴメンだね
146:デフォルトの名無しさん
08/10/22 11:30:38
クライアントから例外もテンプレートも（わからないから）使わないで欲しいって言われた
周辺環境もある意味では言語の問題点に含まれると思う
特にC++の場合、ひとによってスキルの差がありすぎ
せっかくのリソースが活かせないことが多い
まあ割の良い仕事だから我慢するけど、これならCの方が開発効率良いよorz
147:デフォルトの名無しさん
08/10/22 17:05:15
Cの方が開発効率良い、に関しては、
だったらクラスも何も使わないでC同然に書けばいいじゃないと思う。
148:デフォルトの名無しさん
08/10/22 17:14:26
>>146
クラスがあるだけで private とクラスの名前空間があるから
かなり精神的に楽になる。依然マクロの脅威はあるけど。
149:デフォルトの名無しさん
08/10/22 18:05:19
>>147
それならCでいい、というかCのがいいだろ
malloc()の戻り値などをいちいちキャストする必要は無いし
Cリンケージのためにいちいちextern "C"などと書く必要も無い
150:デフォルトの名無しさん
08/10/22 19:03:52
>>149
147でないけど
キャストは new の仕様を促すからそのほうがいいんじゃない。new の方が楽で型安全だし。
extern "C" はCとリンクする部分だけでいいよ。普通の C のライブラリだって extern "C" 使ってるし。
extern "C" を使わないほうが型安全だし。
151:デフォルトの名無しさん
08/10/22 19:18:08
>>150
newは例外まみれで鬱陶しい別の問題を引き起こすだろ
ただの関数形式のアロケータなら差し替えるのも簡単だ
C++をC++らしく使わないという仮定の話をしているようだから
それぐらいならCの方がいいと言ってるんだよ
クラスすら使わないC++で提供される付加価値よりは
グダグダなABIだの、さりげなく仕込まれる例外対策だののほうがずっと鬱陶しい
152:デフォルトの名無しさん
08/10/22 21:07:44
> ただの関数形式のアロケータなら差し替えるのも簡単だ
それと同じくらいnewの差し替えも簡単だ。
void* operator new(std::size_t n)
{
return my_alloc(n); //NULLを返せば例外はthrowされない
}
void operator delete(void* p)
{
my_free(p);
}
//以下コピペするだけ
void* operator new[](std::size_t n)
{
return operator new(n);
}
void operator delete(void* p)
{
operator delete(p);
}
いや、これもずっと鬱陶しい「さりげなく仕込まれる例外対策」の内というならそれまでだけど。
153:デフォルトの名無しさん
08/10/23 00:24:04
bad_allocが嫌ならnothrowつきのnewを使えばいいじゃない
ただ、例外を使わないようにするとどうせNULLチェックをサボる奴が出てくるので
むしろ有害だと思うけどな
154:デフォルトの名無しさん
08/10/23 02:02:52
NULLチェックをサボるために例外を使うってことは、newする部分をまとめてtryに入れるんだろうけど、
スマートポインタかGCでもない限り、メモリリークの危険性がある。
STLで用意されてるauto_ptrはSTLコンテナに食わせられない糞仕様。
155:デフォルトの名無しさん
08/10/23 08:09:11
CAutoPtr
156:デフォルトの名無しさん
08/10/23 11:08:44
>>154
まだ過去の話してんのか
std::tr1::smart_ptrは今では当然のように使う
157:デフォルトの名無しさん
08/10/23 11:46:55
std::tr1::shared_ptrかboost::smart_ptrのどっちかと間違えてるんだと思うが
どっちにしろどうしても必要な所で最低限の使用にしないと重すぎて酷いことになるからなぁ
auto_ptrはそこそこ軽いから割と気軽に使える
まあ、本当は生ポインタが一番いいんだけどな
プログラマが楽をするためだけにスマポの莫大なオーバーヘッドを持ち込むのは感心できない
158:デフォルトの名無しさん
08/10/23 12:17:44
プログラマに苦労を強いると、バグの発生率が跳ね上がるでしょ。
多くの状況ではオーバーヘッドよりバグの方が深刻な問題になるんだから、楽はすべきだと思うけど。
159:デフォルトの名無しさん
08/10/23 13:12:15
C + Boehm GCでいいやん
スマポなんかより便利だし
160:デフォルトの名無しさん
08/10/23 13:21:50
>>157
boost::smart_ptr なんて存在しない。
どっちも shared_ptr。
あとオーバーヘッドなんて大したことないぞ。
ポインタに参照カウントの分の整数がついて回るだけ。
ポインタアクセス時は通常のポインタとほぼ同等
（レジスタ割り付けが多少阻害されるかもしれんが）。
コピーやデストラクト時に参照カウントの増減でこれも一瞬。
161:デフォルトの名無しさん
08/10/23 19:05:25
boost::intrusive_ptr 方式のスマートポインタが好き。
162:デフォルトの名無しさん
08/10/23 20:50:24
UN*X では Objective-C が使えるから無理して C++ を使う必要は無いよね
163:デフォルトの名無しさん
08/10/23 21:02:12
>>162
極一部のUnix以外ではCが主流というオチ。
164:デフォルトの名無しさん
08/10/23 21:22:07
unixだとc++なんか有象無象とひとつ
165:デフォルトの名無しさん
08/10/23 21:28:01
>>154
ようやく次のC++0xで、コンテナに入れられるunique_ptrが入る。
参照カウントせずauto_ptrと全く同じオーバーヘッド。
まったくもって導入が遅すぎる。
166:デフォルトの名無しさん
08/10/27 19:09:41
C++
↓
C++0x
↓
C++(笑)
167:デフォルトの名無しさん
08/10/29 13:28:21
newの例外の問題がなんなのか良くわからんが
template<class T>class vAlloc{
public:
T *m_obj;
vAlloc() : m_obj(NULL){};
vAlloc(int size) : m_obj(NULL){
Alloc(size);
};
~vAlloc(){
delete []m_obj;
};
Alloc(int size){
delete []m_obj;
try {
m_obj = new T[size];
} catch(std::bad_alloc) {
cerr << "メモリを増設してください" << endl;
m_obj = NULL;
exit(0);
}
};
};
こういうクラスを作っといて
vAlloc<char> str1(100);
strcpy(str.m_obj, "Hello");
こうやって利用すればいいんでないの?
168:デフォルトの名無しさん
08/10/29 13:34:53
>>167
言いたい事は分かるけど、コピーコンストラクター位はつけた方がいいと思うんだ
169:デフォルトの名無しさん
08/10/29 13:46:13
「解決できるけどデフォルトで放置されている問題」が多いんだな
170:デフォルトの名無しさん
08/10/29 13:55:15
>>167
なんだそれ
vAlloc<char> str1(100);
なんてやるなら
char str1[100];
でいいだろ
そのクラスはそれ以上のものをそれは何も提供していないし
何の解決にもなっていない
171:デフォルトの名無しさん
08/10/29 14:02:26
STLとかはAllocator差し替えられるけど
alloc()が例外投げること前提に作られてて
NULLチェックなんてしてるわけねーし
C++でデフォのnew捨てるってのは
事実上、標準を含む大半のライブラリを捨てるってこと
172:デフォルトの名無しさん
08/10/29 14:03:41
>>170
何言ってるんだ?
君のコンパイラは、
char str1[strlen(hoge) + 1];
こんな使い方が出来るのか?
173:デフォルトの名無しさん
08/10/29 14:05:16
>>172
ああ、いいたいことは分かった
alloca()っぽいことが出来るんだね
alloca()の代用にしかなってないけど
174:デフォルトの名無しさん
08/10/29 14:09:13
コンストラクタやデストラクタが動くんだからalloca()の代用は言いすぎか
まあ、そういうことが言いたいんじゃなくて、newが使われるシナリオの
ごくごく一部しかカバーできていないだろ、といいたいんだよ
175:デフォルトの名無しさん
08/10/29 14:41:56
>>174
newが使われる際の問題って他にあるの?
176:デフォルトの名無しさん
08/10/29 16:21:08
>>167
そんなことするならset_new_handlerとvector（もしくはboost::scoped_array）で十分だと思う。
177:デフォルトの名無しさん
08/10/29 16:50:22
>>176
newが例外をスローしないようにするのなら
vectorなんて使えないんじゃないのか
new_handlerの中でabort()でも呼ぶのならいいだろうけど、もっと悪いような
178:デフォルトの名無しさん
08/10/29 17:37:38
>>177
> new_handlerの中でabort()でも呼ぶのなら
そういう仮定。だって>>167ではexitだったからこそ。
179:デフォルトの名無しさん
08/10/29 18:06:25
そういうことか。よく見てなかった。
つうかabort()だのexit()だの呼んでる時点でダメだろ
180:デフォルトの名無しさん
08/10/29 19:09:35
俺の探し方が悪いのか、abort()だのexit()だの呼んでる以外のサンプルコードを見た事がない
181:デフォルトの名無しさん
08/10/29 19:13:25
ま、new handlerでできることはそれぐらいだろ
つまり、new handlerは、「それでいい」プログラムにしか使えないってことだよ
182:デフォルトの名無しさん
08/10/29 19:39:56
予めでっかいメモリを確保→newハンドラで解放すれば、
ヒープに空きができてnewを成功させられるぜっていう話を聞いたことがある。
実用性皆無にしか思えない。
183:デフォルトの名無しさん
08/10/30 01:39:17
new handler で必ずしも必要でないキャッシュをパージすることが考えられる。
Java の SoftReference がそんな感じ。
184:デフォルトの名無しさん
08/10/30 09:41:16
bad_allocが発生する様な環境下で、必要のないキャッシュを持つ設計が正しいのだろうか?
185:デフォルトの名無しさん
08/10/30 10:01:22
あっちと内容がかぶってる
C++が糞言語なのはみんな知ってるから一箇所でやってくれないかな
186:デフォルトの名無しさん
08/10/30 13:05:43
どこ？
187:デフォルトの名無しさん
08/11/02 04:11:41
>>172
C++ってそんな事も出来ないのかｗ
188:デフォルトの名無しさん
08/11/02 07:33:07
配列ごときをいちいち動的にヒープに取るような非効率言語とは違うんですっ！
189:デフォルトの名無しさん
08/11/02 08:49:23
>>187
Cにも出来ないけどな
190:デフォルトの名無しさん
08/11/02 11:53:20
>>189
Cは低級言語だから別にいいんだよｗ
191:デフォルトの名無しさん
08/11/02 12:23:05
>>190
'C++'の'C'部分に独自の拡張を加えちゃ駄目じゃん
192:デフォルトの名無しさん
08/11/02 12:37:38
C言語は高級言語だろ・・・
抽象化水準が低いから中級言語って言う奴はいたけど。
193:デフォルトの名無しさん
08/11/02 12:54:55
>>189
C99なら嘆かわしいことに出来てしまう
まあ、あんなものC言語じゃないけどな
194:デフォルトの名無しさん
08/11/03 19:11:25
演算子のオーバーロードはヤバイと
ム半年目の頃に既に俺は思ってたね
関数の引数が参照渡しなのもヤバイ
195:デフォルトの名無しさん
08/11/03 21:30:24
演算子多重定義関数での引数と言えば、const参照が相場だろ。
2行目が値渡しでないからやばいと言っているのであればそれは違う。
196:デフォルトの名無しさん
08/11/03 22:35:07
const参照渡しが安全だと思ってるアホ発見
197:デフォルトの名無しさん
08/11/04 00:23:34
Cに++した程度の言語だ
やばくて当たり前だっての
オブジェクト指向アセンブラに何処まで求めてるんだ?
198:デフォルトの名無しさん
08/11/04 00:39:19
本当に C に ++ してくれたのなら、どんなに良かった事か…
本当の意味で C with Class だったら更に良かったんだがな
残念言語
199:デフォルトの名無しさん
08/11/04 02:52:09
>>192
お前その発言がどんだけ化石か自覚してるのか？
200:デフォルトの名無しさん
08/11/04 09:33:16
C++の++は良く分からん物でオーバーロードされてるだろ
201:デフォルトの名無しさん
08/11/05 18:03:54
もしかしたら実際の処理は--かもしれない
202:デフォルトの名無しさん
08/11/05 18:33:56
そしてC++の仕様上、それを知る事は不可能に近い
203:デフォルトの名無しさん
08/11/06 16:48:48
>194-196のやりとりがよくわかりません。
演算子定義をconst参照で受けて、さらに注意しなければいけないことって何？
204:デフォルトの名無しさん
08/11/06 18:08:29
多分、>>196 にしか解らない深い理由があるんだろう。
205:デフォルトの名無しさん
08/11/06 19:33:21
const_cast
206:デフォルトの名無しさん
08/11/06 20:24:16
それくらいでびくついているようではC++なんて使えないけどな。
全くもってそこらじゅう罠だらけだもん。
207:デフォルトの名無しさん
08/11/06 21:22:36
・constなんてconst_castや普通のキャストで誰でも簡単に外せる
・constを外さなくたってmutableメンバがあれば変更し放題
・deleteに対してconstは全く無力
何かを安全にするつもりでconstを使ってるなら、それは時間の無駄です
constは何も守ってくれません
208:デフォルトの名無しさん
08/11/06 21:45:34
const_cast は使うこと自体が有害だと思われ
209:デフォルトの名無しさん
08/11/06 21:46:39
気休めにしかならないと分かっていても、すがりたくなる。
ほかに信じられるものなんて何もないから。
210:デフォルトの名無しさん
08/11/06 21:51:57
setの要素を変更する時にconst_castは不可欠です
211:デフォルトの名無しさん
08/11/06 21:58:17
あれってconst付いていたっけ？
212:デフォルトの名無しさん
08/11/06 22:04:48
setの要素を直接変更したらまともに動作しないぞ
removeしてからinsertしないと
213:デフォルトの名無しさん
08/11/07 02:46:00
EffectiveSTLの22番だな
214:デフォルトの名無しさん
08/11/07 03:43:36
比較関数が見ないメンバであれば問題ない。
215:デフォルトの名無しさん
08/11/07 09:35:55
const_castなんてC++の問題ではなく、C++を利用するプログラマの問題だろ
216:204
08/11/07 12:14:46
>>207
やっぱりそういう話か。下らん。
217:デフォルトの名無しさん
08/11/07 16:23:46
で、外注先のプログラマに問題が無い事は誰が保障してくれるんだ？
言語側で保障してりゃ良いだけの事を、本当に非効率的な言語(笑)だわ。
218:デフォルトの名無しさん
08/11/07 17:01:39
問題のあるプログラマを雇っている外注なんぞ切ってしまえ
219:デフォルトの名無しさん
08/11/07 17:05:50
また始まった
ぼくはそんなつかいかたしないからC++はわるくないんだい！！
なんか本気で言ってそうでかわいそうになる
220:デフォルトの名無しさん
08/11/07 17:29:08
何のためにconst_castがあるのかも考えず、不用意に使うような奴を擁護する事の方が信じられん
きっと、大阪の轢き逃げみたいな事件を起こすような奴に違いない
221:デフォルトの名無しさん
08/11/07 17:53:25
はいはい、今度は論点のすり替えですね
フルコースですか
次のメニューをお願いします
222:デフォルトの名無しさん
08/11/07 17:54:41
レッテル張りも消化済みでしたね
引き続きどうぞ
223:デフォルトの名無しさん
08/11/07 18:12:17
そもそも、言語側で保障する方が非効率だから、保障しなかったのにね
224:デフォルトの名無しさん
08/11/07 20:36:53
const_castはどう考えても内容を変更しないのになぜか非定数を要求するAPIのためのもの。
Motifやってた頃はお世話になりました。
225:デフォルトの名無しさん
08/11/07 20:59:11
const版・非const版で多重定義するときにも使える。
const char* strchr(const char* s, int c);
inline char* strchr(char* s, int c)
{
const char* t = s;
return const_cast<char*>(strchr(t, c));
}
Cのstrchrより型安全性が増しているという不思議。もっともCとの互換性は無くなったが。
226:デフォルトの名無しさん
08/11/07 23:36:09
アホな事する奴がconst_castなんて律儀に書くわけないという
227:デフォルトの名無しさん
08/11/07 23:42:36
そういうアホは自分に影響が無い程度に放っておけばいいんです。
228:デフォルトの名無しさん
08/11/08 18:01:46
どうしてSTLってstd::の中に全部ぶち込んでるの？
整理とか出来ない人が作ったの？
229:デフォルトの名無しさん
08/11/08 18:40:10
とりあえず、グローバルに全部散らばっているよりは遥かにましです。
230:デフォルトの名無しさん
08/11/08 19:11:13
STLは十分整理されているからそれで困ったことはないよ。
名前空間はいろんな人たちが集まって何かを作るときの応急処置ぐらいに思っておいた方がいいよ。
boostは移行中or統合中とかがあって、一応名前空間で区別してるけど
using使い出すともうカオスになるよね。
231:デフォルトの名無しさん
08/11/08 22:32:08
>>228
あなたならどう整理する？
232:デフォルトの名無しさん
08/11/08 23:17:56
.NETみたいに
233:デフォルトの名無しさん
08/11/09 02:10:38
名前空間も罠の塊だからあんまり多いと困る
234:デフォルトの名無しさん
08/11/09 16:31:19
>>233
using namespaceとか使うから罠に嵌るんじゃないのか?
235:デフォルトの名無しさん
08/11/09 17:00:09
そんなもん使わなくったって落とし穴はいくらでもあるよ
C++にはKoenig Lookupという素敵な仕組みがあるから
236:デフォルトの名無しさん
08/11/10 08:50:37
signed と unsigned の比較くらいできるようにしてくれっつーの！
ヽ(｀Д´)ﾉ
237:デフォルトの名無しさん
08/11/10 12:49:34
signed廃止しようぜ
負の数なんてなくても平気
238:デフォルトの名無しさん
08/11/10 14:23:58
>>226
そういう奴はふつー、Cスタイルのキャスト (万能) 使うよなあ。
239:デフォルトの名無しさん
08/11/10 23:39:57
>>237
そしてsigned_intクラスを作るんでしょ。
240:デフォルトの名無しさん
08/11/11 03:31:15
暗黙の変換がなくなるだけでも上等。
241:デフォルトの名無しさん
08/11/11 10:36:41
分の悪い取引だな