【信者】C++の問題点【アンチ】

1 ：08/10/10 〜 最終レス ：11/12/21

C++の問題点について語るスレです
C++ってなんであんなに肥大化しちゃったの？
http://pc11.2ch.net/test/read.cgi/tech/1219902495/

2 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

3 ：

だからー いちいち禁止しなくても
本物の || && とおんなじ方法で動くようにすればいいだけだろ

4 ：

&&のオーバーロードなんてgotoやlongjmpみたいなもの
使う方が悪い

5 ：

もう飽きた、他のネタ頼むわ

6 ：

そうだな
function-try-blockの話でもしようか

7 ：

ライバルが現れた
gcjって使ってる人います？
http://pc11.2ch.net/test/read.cgi/tech/1046627795/

8 ：

http://shootout.alioth.debian.org/
見ると、ATSって言語が異常に速いんだが
誰か使ってる人いる？

9 ：

|| && 問題なんて「過去との互換性をとるために保守してあるだけで、現在は使わないでください」的なものだろ
Javaだって「将来無くすことになったので、このメソッドは使わないで新しいの使ってね」って言うじゃん。
で、実際に無くすか、互換性のために残しておくか。
どっちが正しいかは白黒なんてつかん

10 ：

なんだこの頭の悪いレスは
アンチのなりすましですか？

11 ：

ウドンズのCreateWindowみたいなものか

12 ：

CreateWindowはObsoleteじゃないだろ

13 ：

C++に限らずif (x) if (y)のシンタックスシュガーとして&&は時々便利に感じる。

14 ：

アイちゃんちょっと頑張り過ぎじゃね？

15 ：

>>13
時々じゃなくてそれに基づいてプログラムを書いてるわけだが
お陰でオーバーロード時に問題が生じてしまったのは禿の責任ではない

16 ：

&& や || をオーバーロードなんてすんなってこった。

17 ：

正しい動作するようにかける方法を
関数以外で提供すれば言いだけ

18 ：

正しいも動作も何も、&&, ||が論理演算である必要すらないのだが。
+を掛け算、*を足し算にして、足し算優先な数式すらつくれるというのに。

19 ：

それはAdd()という名の引き算関数作ることと何が違うの？

20 ：

指数演算ならMul()という名前の足し算関数はありうる

21 ：

>>19
汗の世界では良くあること。

22 ：

>>19
全然違うぜ。
Add(Mul(1, 2), 3)
はあくまでmulを解釈した後addを解釈するし
Mul(Add(1,2), 3)
はAddを先に解釈する
1+2*3
は
1*2+3
としたところで、必ず*が先に解釈される。
プログラムの書き手が解釈順位を決めるのが関数
演算子はコンパイラがすでに解釈順位を決めている。

23 ：

演算子はコンパイラがすでに解釈順位を決めている。
にらそれと同じことをすればいい

24 ：

>>23
まあ、俺もうまく説明できてないが、
問題点を理解できてないのに噛み付かなくてもいいよ。

25 ：

>>24
で、そういうことをするプログラマーが問題ではないと

26 ：

自由と責任は表裏一体。
低レベルの開発ならC並の何でもできる自由度が必要だけど、アプリよりになればなるほど勝手な振る舞いはしてほしくない。
今はハードをベタベタに触る言語とGUIやwebをらくらく使う言語と使い分ける時代じゃねーのかね。
C++は全部やろうとして、肥大化してるし、トラップも増えている感じ。
何でもできるけど、責任はプログラマ側ねという言語は必要だけどすべての分野で使うべきかどうかは疑問だね。

27 ：

本当に自由な言語には使わない自由もあるだろ。
そもそもC++をすべての分野で使うべきなんて誰も言ってないのに勝手に勘違いして
GCを全否定したり無駄な継承したりするのが義務だと思い込んでるだけ。

28 ：

分かってる人は分かった上でC++使ってればいいんだよ。
分からない人が「たくさん」いる現場で使うにはC++はしんどい言語だってこと。

29 ：

流れを読まずにかきこ
GCって何？

30 ：

分かってないのに分かった気になってる人がたくさんいる言語

31 ：

Graphics Context
Grand Central
Gabage Collection

32 ：

nintendo

33 ：

前スレ984、少し改変
あなたは○×言語の問題点を指摘されました
１）「おまえは○×言語もわからない馬鹿だから問題じゃない！」とレッテルを貼る
２）「その問題は俺は(普通は)回避できる(使わない)から問題じゃない！」と論点を摩り替える
３）「△□言語にも同じ問題があるから問題じゃない！」と論点を摩り替える
４）「〜〜という理由でそれは問題とは言えないのではないか？」と論理的に問題無いことを証明する
５）「確かにそこには問題があるね」と素直に認める

34 ：

２と４の違いはなんだ
属人性の排除とかいうやつか

35 ：

2はオールマイティーだな
どんな言語・問題点だろうと普通は使わないからおkって答えればいい

36 ：

包丁やナイフにも人をさせる問題があるが世界中で愛されている

37 ：

ナイフなんかは問題が明らかになれば規制される物だよな

38 ：

包丁やナイフは人をさせるということが予測がつくが、
C++の演算子オーバーロードや例外は想像を超えた害悪があるから問題なんでしょ。

39 ：

つーか包丁は役に立つが
&&のオーバーロードは罠なだけで役に立たん

40 ：

追加
６）「問題はあるけど愛されてるから無問題」と論点を摩り替える
もう何でもアリだなｗｗｗ

41 ：

演算子のオーバーロードは無いと困る機能でもないのに
問題を孕んでるのが嫌らしいよな。結局、無い方がいい。

42 ：

>>41
演算子のオーバーロードは無いと困るだろう

43 ：

演算子オーバーロード全部がまずいのではない
&& || ,
がまずいだけだ
さしあたりはな

44 ：

()、->、newなんかは大活躍ですよ

45 ：

>>40
論点うんぬんは関係ない
ただ根拠がいい加減なだけ

46 ：

operator++()の引数はいらない子

47 ：

>>44
ユーザ定義の演算子を作らなくても実現出来ると思うんだけど

48 ：

そりゃそうだ。どれも関数呼び出しに還元できる。
それ言ったらどの演算子も多重定義できる必要は無い。
複素数やベクトルでa + bと書きたいのと同じようにスマートポインタではp->mと書きたい。

49 ：

屋上屋ってやつか

50 ：

operator->は生ポインタを隠すのに有効
と思ってたけどp.operator->()って普通に出来ちゃうのな
あまり意味がないような気がしてきた

51 ：

あまり意味がないことを悟った上で使えってことじゃね

52 ：

覚えたての厨房が粋がってトリッキーなオーバーロードをしないように気をつけないといけないのが面倒くさい。

53 ：

>>50
そう、隠すためではなく糖衣構文を提供するためのもの。

54 ：

お前らいい加減にしろよ
前スレは10年近く前のネタを1000もかけて焼き直しただけだろ
これ以上一体何を続けるつもりだ？
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

55 ：

その偽ネタインタビューと現在のC++の問題点となんの関係がある？

56 ：

>>55
ヒント:読んだばかり

57 ：

>>55
え？ネタって書いてあるのが読めなかったの？
え？書いてある内容がどんなもんかすらわからなかったの？
え？もしかしてニホンゴワカラナイ？

58 ：

>>57
日本語でおｋ

59 ：

前スレと>>54見てこれなら、真性馬鹿はゆとりとは一味違うな

60 ：

横だが本気で意味わからん
真正馬鹿でもゆとりでもいいから是非日本語で詳しく解説してくれ
ちなみに前スレって一言でまとめると
「斜め上発言でアンチからフルボッコされるドM信者スレ」
だよ？

61 ：

斜め上発言で信者からも「アンチからも」フルボッコされるドMアンチもいました

62 ：

え？そんなの覚えないけど？
すごく興味あるから印象操作じゃないならポインタ示してね

63 ：

>>60
すごく興味あるから印象操作じゃないならポインタ示してね

64 ：

前スレ987
>まぁ信者は問題点に納得した時点で沈黙するからなぁ
>結局新規の馬鹿信者が斜め上発言してアンチがフルボッコにするループはいくらでも続く
前スレ988
>&&批判に反発してた連中は、終わった話を何度も蒸し返して
>無駄に傷口広げてる感じだったな
>しかも禿の仕様ミスであること自体は認めているから
>まともに・論理的には反論できずに
>そんなのは些細なことで問題にするほうがおかしいとか
>斜め上の話ばかりになる

65 ：

ところで、&&や||をオーバーロードすることの何が問題なの?

66 ：

結論から言うと、演算子オーバーロードはＳＴＬ向けの関数オブジェクト作るためだけに使え、
ということだな。

67 ：

, || && は boost::spirit で活躍しているよ。

68 ：

>>66
なぜそれが結論なのかが知りたいのですけど?
一体何が問題なのですか?

69 ：

std::cout << "banana" << count << std::endl;
(ノ ﾟДﾟ)ノ　＝＝＝＝　┻━━┻

70 ：

コンテナ継承させてよぅ

71 ：

ただの質問スレだったら、protected継承でいいじゃないって答えるところだな。

72 ：

>>65
組み込み型に対する&&や||は短絡といって、
左から順に評価していって、
結果が分かったらそれ以降の評価を行わない仕組みになってる。
たとえば、
bool f1(); bool f2();
if ( f1() && f2() )
という式があったとすると、f1が偽の場合、f2は評価されないことが保証される。
しかし、&&や||のオーバーロードの場合は関数呼び出しと解釈されるため、短絡がない。
それどころか、関数呼び出し順序は標準に規定されていないため、
どちらが先に評価されるかすら分からない。
my_bool b1(); my_bool b2();
if ( b1() && b2() )
この場合、b1とb2のどちらが先に評価されるか分からない(処理系依存)。
分かりにくいバグの元になる、コードの可搬性を損なう、などの理由から
&&や||のオーバーロードは推奨されない。

73 ：

>>72
つまり、&&オーバーロードは、+等のオーバーロードとは違う解釈で実行されるってことなの?
それなら、大きな問題だなぁ...

74 ：

>>組み込み型に対する&&や||は短絡といって、
それと同じ構造にすればいいだろ

75 ：

>>74
C#とかそれを目指している。
C++でもBoost.Lambdaは頑張った。
あと今から同じ構造になる仕組みをC++に持ち込んだとしても、
「互換性のため」現状の&&と||もそのまま残ること間違いない。

76 ：

比較的どうでもいい豆知識だな

77 ：

遅延評価の考え方がどうでもいい豆知識っすか
Cにどっぷりはまるとそうなっちゃうのね

78 ：

短絡評価 short-circuit evaluation と遅延評価 lazy evaluation はまったくの別物だぞ
遅延評価は、必要になるまで変数の値の計算を先延ばしにするHaskellのアレだ

79 ：

同じ様なもんだろ
右オペランドを遅延評価することを短絡評価という

80 ：

じゃあ評価は？

81 ：

>79
遅延評価はもっと広い意味の言葉だから混同するとややこしい。

82 ：

>>64
何の指摘にもなってないよ

83 ：

オーバーロード関数のDLLが・・・

84 ：

>>83
日本語でok

85 ：

オーバーロードしたら&&が論理和どころか論理演算ですらある必要がないので、
通常と同じ動作にしたらいいじゃんという主張は無意味だろ。

86 ：

演算子の元の意味と大きく異なるオーバーロードは駄目だろ
おまえは+が加算である必要が無いからって乗算にするのか？

87 ：

＞ 演算子の元の意味と大きく異なるオーバーロードは駄目だろ
そこで << ですよ

88 ：

>>72
良く分からんが
if ( b1 && b2 )
は
if ( b1.operator&&(b2) )
と等価じゃないの?

89 ：

常識という眼鏡で僕達の世界はのぞけやしないのさ
夢を忘れた古いプログラマーたちよ
アンドじゃないアンドじゃない
素敵な世界

90 ：

>>88
operator&&() が my_bool のメンバならね。
でも
    bool operator&&(const my_bool& a, const my_bool& b)
かも知れない。
更に、b1 が左辺値ではなく my_bool を戻す式だったとき、
やっぱり b2 とどっちが先に評価されるかは判らない。

91 ：

>>90
引数の評価順を重要視する意味がよくわからん
引数の時点で、真偽がわかったとしても関数から抜け出す手段は無いとおもうが?
b1 && b2 && b3
の式の場合
operator&&(operator&&(b1, b2), b3)
となって、operator&&(b1, b2)が偽の場合でも、一番外側のoperator&&()が実行されるから嫌だって事なら、ちょっとだけ理解できるかもしれないが
だからと言って、C++の欠陥だと大声で言うようなものでも無いと思うのですが

92 ：

>>91
短絡評価のメリットが解らない、ってこと？

93 ：

>>92
短絡評価のメリットを受けられるほど長い論理式を使うつもりなのですか?
それとも、短絡評価のメリットを受けられるほどのif文の山を築く気ですか?

94 ：

話がまた斜め上の方向に捩れてるな
>>91
if 式 文
で式の内容如何によらず文が評価されていいと思ってるのか？
遅延評価無しではif文を関数化することは出来ない
だから禿も?:はoperator化していない
にもかかわらず、同様の機能を持っている&&や||をoperator化しているのが
マヌケだという話だろ
>>93
言語仕様の問題をプログラミングスタイルの方向に摩り替えたい人発見

95 ：

バグの原因は小さいものだから
大きな問題ではないと考えるのも無理はない

96 ：

INT i=1,j=1; //なんかint的なクラスだと思いね
i++ || j++;
cout << i << "," << j;
||がオーバーロードされていなければ「2,1」が表示される
されていれば「2,2」が表示される
open(file) && abort();
&&がオーバーロードされていなければ、ファイルオープンに成功すれば処理が続行される
されていればファイルオープンに成功したのに異常終了する

97 ：

>>94
論理式は論理式だろ?
if文や三項演算子とは関係ないんじゃない?
>>96
むしろ、その使い方が、言語仕様の悪用だと思います

98 ：

>>97
いや、ショートサーキットの&&や||はifの変種みたいなもんだぞ
C/C++に引きこもっているうちは分からないかもしれないが、
他の言語もやってみれば分かるよ

99 ：

つーか短絡評価しないなら&や|だけでいい
何のためにわざわざ&&や||が用意されてると思ってるんだ

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
ARToolKitでARを作ろう
localeをロケールと言う人って何なの？
デルヒの、オジェスト思考に、ついて
言語ってObjective-Cだけでよくね