TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
C#, C♯, C＃相談室 Part95
[RPA]PC自動化技術総合スレ[効率化] Part.6
【消しゴム】MONOを使ってみるスレ4【じゃない】
Pythonのお勉強 Part57
D言語 Part34
【統計分析】機械学習・データマイニング26
Pythonのお勉強 Part62
低スキルでも読めるコードは、属人的なコードになる
C++相談室 part143
【Delphi】Embarcaderoオッチャ その31【C++ﾋﾞﾙﾀﾞ】

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


1 ：2008/10/10 〜 最終レス ：2018/07/05
C++の問題点について語るスレです
C++ってなんであんなに肥大化しちゃったの？
http://pc11.2ch.sc/test/read.cgi/tech/1219902495/

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

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

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

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

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

7 ：
ライバルが現れた
gcjって使ってる人います？
http://pc11.2ch.sc/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 ：
つーか短絡評価しないなら&や|だけでいい
何のためにわざわざ&&や||が用意されてると思ってるんだ

100 ：
>>99
それもちょっと違うけどな
1 && 2は真だけど 1 & 2は0だし

101 ：
そうだな
ごめんアホなこと言った

102 ：
>>98
論理式が返すのは、論理値だろ
論理式の処理過程を期待してプログラムするってのは、真値が特定の値である事を期待してプログラムするのと同じじゃん

103 ：
>>102
そうだよ、一部ではもはやただの論理式ではなく制御構造と見なされているということ。
C++ではあまり見ないけど、PerlとかでHogeHoge or dieとか。

104 ：
>>102
＞論理式の処理過程を期待してプログラムする
「期待」じゃなくてC/C++は「仕様で」「明確に」「わざわざ」評価順を
定義しているわけだが
&& || に関してはな
何の意味も無くそんな仕様にしてると思ってんの？
ま、&&や||は論理演算、bool代数だよな？そこはその通りだ。
フローコントロールもセマンティクスも変えちまう
オーバーロードなんてもってのほかだよな？

105 ：
bool banana;
if(!banana)
{
// ↑気持ち悪いねこれ。
}

106 ：
if(true != banana)
if(false == banana)
好きなほうを選べ

107 ：
VB.NETではVBには無かった短略評価の
AndAlso OrElse という（キモい）演算子が追加されているのだが
その意味も分からないんだろうねえ

108 ：
>>104
言ってることがわからない
&&や||をオーバーロードできるように定義しているのも「仕様」なんじゃないの?

109 ：
>>108
だから、その仕様が不整合で良くないっつー話をしてるんだろ
言うまでも無く後から突っ込んだオーバーロードの仕様がマズい

110 ：
&&や||をオーバーロードの場合はコンパイラが短絡すればいいだけだろ

111 ：
何だそれ
互換性が無くなってさらにカオスになるだけじゃねえか

112 ：
&&と||の意味がわかんねー奴はC++厨気取りたいんなら
More Effective C++ぐらい嫁

113 ：
.front()も.begin()も同じで良いジャン
なんで違うの

114 ：
>>113
hoge.front()は*hoge.begin()相当。
強いて言えば、beginからfrontは取り出せるが逆は一般にできないんでfrontがやや余計かな。

115 ：
front取り忘れたのかね

116 ：
map持っていて
<<でkeyを流し込んだら valueが返ってくるクラスはあり？

117 ：
演算子でやる理由がわからん

118 ：
>>116
[]演算子で標準装備してない？
まあこれはkeyを持ってなかったらvalueにはデフォルトコンストラクタで生成
した値が代入されてしまうんだけど

119 ：
[]だとポインタのとき面倒じゃね？

120 ：
value = (*hogemap)[key]
でおけ

121 ：
あえて operator()

122 ：
ttp://homepage2.nifty.com/well/Operator.html#arrow_ast

なんでもあり

123 ：
>>119
いやポインタに対して使うときは全部だろ

124 ：
C++のIDEに自動的にヘッダやnamespaceを宣言してくれる奴って何かあります？
Javaとかだと適当にクラス使ってもクラスパスから候補探してくれるのがメジャーなIDEの基本機能にある。

125 ：
>>124
ゆとりは黙ってろよ(笑)
そんな余計な機能はIDEには要らない

126 ：
自動的にヘッダを追加するようなIDEは怖くて使えません

127 ：
さすが生産性の無さでユーザーがみるみる減っている言語だけはあるｗ

128 ：
>>124
C++のヘッダのincludeは単なるプリプロセッサ命令で、やってることは
原始的なコピペ
Javaは自己記述的なjarやclassからシンボルをインポートしてるわけだ
C++でそういうことをやるのは技術的に不可能ではないだろうが
向いているとは思えんな
現代的なIDEなどが出るよりはるか以前に作られた化石言語なのだから仕方が無い

129 ：
C++はIDEととことん相性悪いからな
まるでIDEを妨害しようとしているかのような仕様
VSやBuilderやCDTはマジ頑張ってると思うのですよ
頭が下がる

130 ：
C++を有難がって使ってる奴なんているの？
居たとしたらちょっと馬鹿すぎる

131 ：
文句なしの代替が無いから使っているだけだよ。

132 ：
有難がって使うプログラミング言語なんてないだろ。

133 ：
>>130
C#がネイティブ初めから吐いてくれたらそっちに移行したいんだが
仕方ないからC++を使ってる
つーかC#プログラマ恵まれ過ぎだろ・・・

134 ：
C++が一番簡単だから使ってる

135 ：
結局、

136 ：
結局、このスレにC++信者なんて居なかったってオチか

137 ：
>>105
↑頭悪いねこれ。

138 ：
C++が最高だと思って使ってる奴はいないだろ。
ただ分かってない上司やクライアントがいるからC++の仕事もあるってだけだ。
本当はCで十分だったり、C#やJavaの方が効率良かったりするんだが。

139 ：
C#やJavaをフロントエンドにして、
OS依存部分や、処理が思い部分を
C言語で書くスタイルがベストだな。
既にOracleがそうだし、CADもそういうのがある。

140 ：
C++はプログラム初級〜中級者向けのおもちゃとしてはそこそこ面白い
だが普通はすぐに暗黒面に気付いて使うのを辞めるor仕事で仕方なく使うだけだ

141 ：
その通り過ぎて何も言えねえ…
良い代替言語があれば良いんだけどね

142 ：
D言語がふらふらしてなければなｗ
創始者が「仕様変えるぞー」を未だに自粛しないからこまったものだ。

143 ：
まあ暗黒面に気付かないうちはまだまだ初心者ってことだ
それに気付いた時にはバッドノウハウばかりで他言語に応用が効かないのも悔しいところだ

144 ：
Plan9(笑)
D言語(笑)

145 ：
バッドノウハウを追求するのは楽しい
しかしチームでやる仕事ではゴメンだね

146 ：
クライアントから例外もテンプレートも（わからないから）使わないで欲しいって言われた
周辺環境もある意味では言語の問題点に含まれると思う
特にC++の場合、ひとによってスキルの差がありすぎ
せっかくのリソースが活かせないことが多い
まあ割の良い仕事だから我慢するけど、これならCの方が開発効率良いよorz

147 ：
Cの方が開発効率良い、に関しては、
だったらクラスも何も使わないでC同然に書けばいいじゃないと思う。

148 ：
>>146
クラスがあるだけで private とクラスの名前空間があるから
かなり精神的に楽になる。依然マクロの脅威はあるけど。

149 ：
>>147
それならCでいい、というかCのがいいだろ
malloc()の戻り値などをいちいちキャストする必要は無いし
Cリンケージのためにいちいちextern "C"などと書く必要も無い

150 ：
>>149
147でないけど
キャストは new の仕様を促すからそのほうがいいんじゃない。new の方が楽で型安全だし。
extern "C" はCとリンクする部分だけでいいよ。普通の C のライブラリだって extern "C" 使ってるし。
extern "C" を使わないほうが型安全だし。

151 ：
>>150
newは例外まみれで鬱陶しい別の問題を引き起こすだろ
ただの関数形式のアロケータなら差し替えるのも簡単だ
C++をC++らしく使わないという仮定の話をしているようだから
それぐらいならCの方がいいと言ってるんだよ
クラスすら使わないC++で提供される付加価値よりは
グダグダなABIだの、さりげなく仕込まれる例外対策だののほうがずっと鬱陶しい

152 ：
> ただの関数形式のアロケータなら差し替えるのも簡単だ
それと同じくらい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 ：
bad_allocが嫌ならnothrowつきのnewを使えばいいじゃない
ただ、例外を使わないようにするとどうせNULLチェックをサボる奴が出てくるので
むしろ有害だと思うけどな

154 ：
NULLチェックをサボるために例外を使うってことは、newする部分をまとめてtryに入れるんだろうけど、
スマートポインタかGCでもない限り、メモリリークの危険性がある。
STLで用意されてるauto_ptrはSTLコンテナに食わせられない糞仕様。

155 ：
CAutoPtr

156 ：
>>154
まだ過去の話してんのか
std::tr1::smart_ptrは今では当然のように使う

157 ：
std::tr1::shared_ptrかboost::smart_ptrのどっちかと間違えてるんだと思うが
どっちにしろどうしても必要な所で最低限の使用にしないと重すぎて酷いことになるからなぁ
auto_ptrはそこそこ軽いから割と気軽に使える
まあ、本当は生ポインタが一番いいんだけどな
プログラマが楽をするためだけにスマポの莫大なオーバーヘッドを持ち込むのは感心できない

158 ：
プログラマに苦労を強いると、バグの発生率が跳ね上がるでしょ。
多くの状況ではオーバーヘッドよりバグの方が深刻な問題になるんだから、楽はすべきだと思うけど。

159 ：
C + Boehm GCでいいやん
スマポなんかより便利だし

160 ：
>>157
boost::smart_ptr なんて存在しない。
どっちも shared_ptr。
あとオーバーヘッドなんて大したことないぞ。
ポインタに参照カウントの分の整数がついて回るだけ。
ポインタアクセス時は通常のポインタとほぼ同等
（レジスタ割り付けが多少阻害されるかもしれんが）。
コピーやデストラクト時に参照カウントの増減でこれも一瞬。

161 ：
boost::intrusive_ptr 方式のスマートポインタが好き。

162 ：
UN*X では Objective-C が使えるから無理して C++ を使う必要は無いよね

163 ：
>>162
極一部のUnix以外ではCが主流というオチ。

164 ：
unixだとc++なんか有象無象とひとつ

165 ：
>>154
ようやく次のC++0xで、コンテナに入れられるunique_ptrが入る。
参照カウントせずauto_ptrと全く同じオーバーヘッド。
まったくもって導入が遅すぎる。

166 ：
C++
↓
C++0x
↓
C++(笑)

167 ：
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 ：
>>167
言いたい事は分かるけど、コピーコンストラクター位はつけた方がいいと思うんだ

169 ：
「解決できるけどデフォルトで放置されている問題」が多いんだな

170 ：
>>167
なんだそれ
vAlloc<char> str1(100);
なんてやるなら
char str1[100];
でいいだろ
そのクラスはそれ以上のものをそれは何も提供していないし
何の解決にもなっていない

171 ：
STLとかはAllocator差し替えられるけど
alloc()が例外投げること前提に作られてて
NULLチェックなんてしてるわけねーし
C++でデフォのnew捨てるってのは
事実上、標準を含む大半のライブラリを捨てるってこと

172 ：
>>170
何言ってるんだ?
君のコンパイラは、
char str1[strlen(hoge) + 1];
こんな使い方が出来るのか?

173 ：
>>172
ああ、いいたいことは分かった
alloca()っぽいことが出来るんだね
alloca()の代用にしかなってないけど

174 ：
コンストラクタやデストラクタが動くんだからalloca()の代用は言いすぎか
まあ、そういうことが言いたいんじゃなくて、newが使われるシナリオの
ごくごく一部しかカバーできていないだろ、といいたいんだよ

175 ：
>>174
newが使われる際の問題って他にあるの?

176 ：
>>167
そんなことするならset_new_handlerとvector（もしくはboost::scoped_array）で十分だと思う。

177 ：
>>176
newが例外をスローしないようにするのなら
vectorなんて使えないんじゃないのか
new_handlerの中でabort()でも呼ぶのならいいだろうけど、もっと悪いような

178 ：
>>177
> new_handlerの中でabort()でも呼ぶのなら
そういう仮定。だって>>167ではexitだったからこそ。

179 ：
そういうことか。よく見てなかった。
つうかabort()だのexit()だの呼んでる時点でダメだろ

180 ：
俺の探し方が悪いのか、abort()だのexit()だの呼んでる以外のサンプルコードを見た事がない

181 ：
ま、new handlerでできることはそれぐらいだろ
つまり、new handlerは、「それでいい」プログラムにしか使えないってことだよ

182 ：
予めでっかいメモリを確保→newハンドラで解放すれば、
ヒープに空きができてnewを成功させられるぜっていう話を聞いたことがある。
実用性皆無にしか思えない。

183 ：
new handler で必ずしも必要でないキャッシュをパージすることが考えられる。
Java の SoftReference がそんな感じ。

184 ：
bad_allocが発生する様な環境下で、必要のないキャッシュを持つ設計が正しいのだろうか?

185 ：
あっちと内容がかぶってる
C++が糞言語なのはみんな知ってるから一箇所でやってくれないかな

186 ：
どこ？

187 ：
>>172
C++ってそんな事も出来ないのかｗ

188 ：
配列ごときをいちいち動的にヒープに取るような非効率言語とは違うんですっ！

189 ：
>>187
Cにも出来ないけどな

190 ：
>>189
Cは低級言語だから別にいいんだよｗ

191 ：
>>190
'C++'の'C'部分に独自の拡張を加えちゃ駄目じゃん

192 ：
C言語は高級言語だろ・・・
抽象化水準が低いから中級言語って言う奴はいたけど。

193 ：
>>189
C99なら嘆かわしいことに出来てしまう
まあ、あんなものC言語じゃないけどな

194 ：
演算子のオーバーロードはヤバイと
ム半年目の頃に既に俺は思ってたね
関数の引数が参照渡しなのもヤバイ

195 ：
演算子多重定義関数での引数と言えば、const参照が相場だろ。
2行目が値渡しでないからやばいと言っているのであればそれは違う。

196 ：
const参照渡しが安全だと思ってるアホ発見

197 ：
Cに++した程度の言語だ
やばくて当たり前だっての
オブジェクト指向アセンブラに何処まで求めてるんだ?

198 ：
本当に C に ++ してくれたのなら、どんなに良かった事か…
本当の意味で C with Class だったら更に良かったんだがな
残念言語

199 ：
>>192
お前その発言がどんだけ化石か自覚してるのか？

200 ：
C++の++は良く分からん物でオーバーロードされてるだろ

201 ：
もしかしたら実際の処理は--かもしれない

202 ：
そしてC++の仕様上、それを知る事は不可能に近い

203 ：
>194-196のやりとりがよくわかりません。
演算子定義をconst参照で受けて、さらに注意しなければいけないことって何？

204 ：
多分、>>196 にしか解らない深い理由があるんだろう。

205 ：
const_cast

206 ：
それくらいでびくついているようではC++なんて使えないけどな。
全くもってそこらじゅう罠だらけだもん。

207 ：
・constなんてconst_castや普通のキャストで誰でも簡単に外せる
・constを外さなくたってmutableメンバがあれば変更し放題
・deleteに対してconstは全く無力
何かを安全にするつもりでconstを使ってるなら、それは時間の無駄です
constは何も守ってくれません

208 ：
const_cast は使うこと自体が有害だと思われ

209 ：
気休めにしかならないと分かっていても、すがりたくなる。
ほかに信じられるものなんて何もないから。

210 ：
setの要素を変更する時にconst_castは不可欠です

211 ：
あれってconst付いていたっけ？

212 ：
setの要素を直接変更したらまともに動作しないぞ
removeしてからinsertしないと

213 ：
EffectiveSTLの22番だな

214 ：
比較関数が見ないメンバであれば問題ない。

215 ：
const_castなんてC++の問題ではなく、C++を利用するプログラマの問題だろ

216 ：
>>207
やっぱりそういう話か。下らん。

217 ：
で、外注先のプログラマに問題が無い事は誰が保障してくれるんだ？
言語側で保障してりゃ良いだけの事を、本当に非効率的な言語(笑)だわ。

218 ：
問題のあるプログラマを雇っている外注なんぞ切ってしまえ

219 ：
また始まった
ぼくはそんなつかいかたしないからC++はわるくないんだい！！
なんか本気で言ってそうでかわいそうになる

220 ：
何のためにconst_castがあるのかも考えず、不用意に使うような奴を擁護する事の方が信じられん
きっと、大阪の轢き逃げみたいな事件を起こすような奴に違いない

221 ：
はいはい、今度は論点のすり替えですね
フルコースですか
次のメニューをお願いします

222 ：
レッテル張りも消化済みでしたね
引き続きどうぞ

223 ：
そもそも、言語側で保障する方が非効率だから、保障しなかったのにね

224 ：
const_castはどう考えても内容を変更しないのになぜか非定数を要求するAPIのためのもの。
Motifやってた頃はお世話になりました。

225 ：
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 ：
アホな事する奴がconst_castなんて律儀に書くわけないという

227 ：
そういうアホは自分に影響が無い程度に放っておけばいいんです。

228 ：
どうしてSTLってstd::の中に全部ぶち込んでるの？
整理とか出来ない人が作ったの？

229 ：
とりあえず、グローバルに全部散らばっているよりは遥かにましです。

230 ：
STLは十分整理されているからそれで困ったことはないよ。
名前空間はいろんな人たちが集まって何かを作るときの応急処置ぐらいに思っておいた方がいいよ。
boostは移行中or統合中とかがあって、一応名前空間で区別してるけど
using使い出すともうカオスになるよね。

231 ：
>>228
あなたならどう整理する？

232 ：
.NETみたいに

233 ：
名前空間も罠の塊だからあんまり多いと困る

234 ：
>>233
using namespaceとか使うから罠に嵌るんじゃないのか?

235 ：
そんなもん使わなくったって落とし穴はいくらでもあるよ
C++にはKoenig Lookupという素敵な仕組みがあるから

236 ：
signed　と　unsigned　の比較くらいできるようにしてくれっつーの！
ヽ(｀Д´)ﾉ

237 ：
signed廃止しようぜ
負の数なんてなくても平気

238 ：
>>226
そういう奴はふつー、Cスタイルのキャスト (万能) 使うよなあ。

239 ：
>>237
そしてsigned_intクラスを作るんでしょ。

240 ：
暗黙の変換がなくなるだけでも上等。

241 ：
分の悪い取引だな

242 ：
enumの仕様をC#と同じに変えてほしいな

243 ：
>>242 次の改訂で入る enum class でいいか？
http://en.wikipedia.org/wiki/C%2B%2B0x#Strongly_typed_enumerations

244 ：
いやもう改訂とかどうでもいいです
9割の案件でC#使ってるんで

245 ：
もう来るなよ。

246 ：
問題はその1割のC++案件がストレスの9割を占めている点なんだが
ほんと、さっさと消えろよゴミ言語が

247 ：
>>243
それがあればよさそうだ
改訂版が待ち遠しいぜ

248 ：
規格発行が 2010 だから、すでに先行して実装が進んでることから考えて
まともな処理系が使えるようになるのが 2012 ぐらいかな？そこから一般の仕事で
使えるぐらいに日本で普及するのが 2015 ぐらいじゃね？

249 ：
6年後か
さすがにC++終わってそうだなｗ
今C++で張り切ってる中年組は全部リストラ済みだろうし

250 ：
JavaとC#に支配された世界もゾッとしないけどなー
その頃Dは7.0くらいになってるんだろうか

251 ：
ネイティブコードを吐き出せるいかした言語がでるまで、C/C++は終わらねぇだろ
どうやって、JavaやC#を実装するつもりだよ

252 ：
いや、Cは残るだろ
アホか

253 ：
念のため>>252は>>251宛てな
聳え立つ糞の塊のC++とCを一緒にすんなカス

254 ：
「C/C++」
こんな書き方発明した糞野郎は誰なんだろうな全く

255 ：
Cが残って、C++が残らないって、意味が分からんw

256 ：
　　　　 　　　 　　　∩＿　
　　　　　　　　　 　〈〈〈　ヽ
　　　　　　　　　　〈⊃　　}
　　 ∩＿＿＿∩　 |　　 |
　　 | ノ　　　　　 ヽ !　　 !
　　/　　●　　　● |　　/
　 |　　　　( _●_)　 ミ／ こいつ最高にアホ
　彡､　　　|∪|　　／
/　＿＿　 ヽノ　/
(＿＿＿）　　　/

257 ：
managed C++より、unmanaged C#を作ってほしい。

258 ：
最近の動向を見てるとC++が残らなくても驚かない。
CはUNIXカーネルの大半がCで書かれている限り残る。

259 ：
Objective-C は Mac が方針を変えない限りは残る。

260 ：
>>259
s/Mac/Apple/gな。今やiPhoneにも使用されている言語だ。

261 ：
態々置換文書くって何なの？日本語不自由なの？

262 ：
>>261
流行ってるから言ってみたのか？

263 ：
>>262
は？

264 ：
>>261
>>262 が答えらしいよ。

265 ：
アンカミスですか

266 ：
〜って何なの？死ぬの？

267 ：
ケンカはやめて（＞＜）

268 ：
二人をとめて〜

269 ：
河合奈保子出てくるとか、どんだけ歳ｙ（ｒｙ

270 ：
仕事ではわけわからなくなるのでboostは使っていない。標準が一番だ。

271 ：
つまりC++には実用性のあるライブラリが一つも無い
一体何十年使われ続けてこのザマだよ

272 ：
C++の問題点
　　R　u　b　y　で　は　な　い　こ　と
わかったかクズどもｗ

273 ：
はいはいスルースルー

274 ：
>>271
お前のいるセカイには、そもそも何ひとつないんだろ？

275 ：
河合って誰だよ
竹内まりやだろ

276 ：
C++頑張りすぎだろ、

277 ：
最近、明らかに経験不足な連中が使いたがっている／使わされてるケースを見かけるんだが
何かあんのかね？
まずはJavaだの.NETだので基本やってくれって思う

278 ：
いまメモリどんくらい使ってんのかガチでわかり難い
なんか仕掛けいれておかないとこのへんの管理ができない
他の言語もそうだけど

279 ：
それがわかりやすい言語ってあるの？
いや、GCがいる言語はGCに聞けば教えてくれるのかもしれないけど
そういうのはそもそもメモリ使用量の制御自体出来ないじゃない

280 ：
別に OS の機能でメモリ使用量を吐き出せるっしょ。
コンシューマゲーム作ってるというのであれば話は別になるかもしれないが。

281 ：
たとえばfree(3)してもOSに返すわけじゃない
どのサイズを知りたいかによるけど、言語レベルでは難しいだろうね

282 ：
本気でメモリ管理したいなら多くのOSで直接システムコールができるC/C++はむしろ有利なほう

283 ：
>>282
メモリ管理如きにそんな潤沢な予算を回せる案件は無い
寝言は寝て言え

284 ：
メモリが足りないようなら管理きちっとするだろ・・・常識的に

285 ：
>>284
ハード買わせた方が圧倒的に安い

286 ：
メモリを数ギガ使うようなアプリだと結局ねえ。

287 ：
組み込み機器だと数MBのメモリを必死でやりくりするようなケースはよくある
PCのアプリがプログラムの全てだと思うな

288 ：
はいはい、二言目には組み込みね

289 ：
ん？
組み込みのほうが格が上というのは常識だが？

290 ：
組み込みなんて誰でも出来るだろ
あんなのプログラムじゃねえよ

291 ：
組み込みって土方の中の土方ってイメージがある

292 ：
アプリケーションとハードを繋ぐためだけのコードをひたすら書く仕事だからな
気が狂うわ

293 ：
安い人間使った方が良いだけで
全然人間的思考が必要な物じゃないからな、組み込み

294 ：
改めて流れ見たけど>>287は本当にばかだなぁ

295 ：
組み込み屋ごときの低レベルな頭で偉そうなことを言おうとすると
こうなるというよい見本だったな

296 ：
だいたい、組み込みはリソース独占できるんだから、他の縁もゆかりもないアプリとメモリを調整する必要ないし。

297 ：
右から左にデータ流すだけでメモリなんかそんなに消費するわけないだろ
どんだけ下手くそなコード書いてるんだろ

298 ：
組み込みでlispとかhaskell使いたい

299 ：
組み込み叩きの自演が酷いなｺﾚ。

300 ：
命にかかわるような致命的な間違いを起こしてきたのは何時だって組込の奴らだし

301 ：
そうでもない。

302 ：
class A
{
virtual void func(void) {}
};
class B : public A
{
virtual void func(void) {}
};
class C : public B
{
virtual void func(void) { A::func(); }
};
こんな記述ができてしまうC++はクソ。
is a関係破壊してるしｗｗｗ
Java見習え

303 ：
>>302
関係破壊してるのはお前だろjk
C++は自由度が高いがそれを利用するもしないも全部
プログラマの責任
つまりお前はヘボグラマ

304 ：
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
class Test
{
public:
static void* operator new(size_t size,void* ptr){
delete (char*)ptr;
return NULL;
}
static void operator delete(void* ptr){
char** p = (char**)ptr;
*p = new char[256];
}
};

int main(void)
{
char* ptr;
delete (Test*)&ptr;
memcpy(ptr,"fuckin' C++",sizeof("fuckin' C++"));
printf("%s\n",ptr);
new(ptr) Test;
return 0;
}

305 ：
>>304
delete[] (char*)ptr;でしょ。

306 ：
[]抜けてたｗｗｗ
まあ、この場合は余り影響ないだろうけど

307 ：
C++なんて糞言語にいつまでもへばり付いてないで、いい加減C#へ旅立とうぜ？

308 ：
研究者はC++を好んで使う
なぜなら自分で責任を取れるなら最も自由を与えてくれるのが
この言語において他は無いからだ
というか最早言語でさえない
メタ言語だ

309 ：
メタって言いたいだけ。

310 ：
滅多メタ

311 ：
そのうちカーズは考えるのをやメタ

312 ：
アセンブリソースを吐けるんだからメタ言語なのは当たり前の事だろ

313 ：
>>312
>アセンブリソースを吐ける
のはコンパイラであって、言語ではありません。
>だからメタ言語
意味不明。

314 ：
コードジェネレータは全てメタ言語だという主張だろう。
意味不明ということは無い。
言及する価値も無いが。

315 ：
タメグチ言語だ

316 ：
>>312
コンパイラはコードをアセンブラに変換する。
メタ言語はコードを生成する。

317 ：
肥大化って一体何のこといってるの？
メモリが貧弱な組み込みデバイスでもC++のコードは思い通りに動いてくれてますけど。

318 ：
わからないなら黙ってれば

319 ：
>>317
>肥大化って一体何のこといってるの？
ヘタクソが作るとメモリ使用量が爆発的に増加する現象。
C++ や Java に対する無知が生む悲劇。

320 ：
>>319
それってC++自体の「肥大化」とは全く関係なくない？
ヒープにあるオブジェクトをdeleteするとき、関連する全てのポインタを
自動的に全部無効にして欲しいとかは思ったことあるけど。

321 ：
>>320
スマポを使えば無効にしてくれるよ。

322 ：
スマポは無意味な肥大化だよな

323 ：
いや、十分意味があるだろ。肥大化でも無いし。

324 ：
スマポには嫌らしい落とし穴が

325 ：
使わないともっとでかい穴が開きっぱなしなんだがな。

326 ：
結局馬鹿が使えば穴開きっぱなしなんだから無駄な肥大化じゃねって言う

327 ：
そんな馬鹿は最初からC++なんて使うな。
JavaかC#使っておけ

328 ：
なんでこんなに必死なのかな？
スマートポインタに意義があると困っちゃう人って、どんな人だろう？

329 ：
>>320
>C++自体の「肥大化」
kwsk
「仕様の肥大化」と >>319 以外に
何が「肥大化」すると？

330 ：
10年ぶりに触ったが、すっかり忘れてる。
テンプレート周りのコンパイルエラーが全然、理解できない。
関数からローカル変数の参照返して、例外起こしちゃうし…
受け側でコピーコンストラクタ用意しておけば大丈夫って思ってたけど、
一時変数とごっちゃになっていたらしい。
しばらくリハビリが必要そうだ…

331 ：
テンプレート絡みのエラーメッセージが意味不明なのはしょーがない。

332 ：
ま　さ　に　肥　大　化

333 ：
権限と責任はセットで与えられて然るべきものである
よって責任を負えない素人や才無き者はC++に触れてはならない

334 ：
消去法でC++って人は多いんじゃないの？
ネイティヴコンパイルで他にいい言語って何よ？

335 ：
D言語
Objective-C
Object Pascal

336 ：
やっぱりどれもぱっとしないな

337 ：
いずれすべてＣ＃に統合されると港では言われてるけど本当なの？(´･ω･`)

338 ：
>>337
頭の悪い巷があったもんだ。

339 ：
Native C# か Native VB が出ればC++は捨てていい。
D言語ってまだ話題になってるのか？

340 ：
Ｋコンパイラなら・・・

341 ：
>>339
つ[ngen]
ところが、世の中 Windows だけじゃないんだが。

342 ：
GCC+C言語、C++が無いと
Linuxの世界じゃ生きていけない

343 ：
>>341
つ[ngen]
おおっ！こんなのが出てるんですね。
C#に乗り換えようかなぁ。
でも、どっぷりとC++につかってるし、FORTRANに次ぐ
スピードといったらC++しかないからなぁ。
あ、>>339は一般論ではなく、俺的にはと言ったまでです。

344 ：
おまえらがんばって落とし穴のないスマポ作ってくれ

345 ：
ただメジャーになってくれないと解説本とかが充実しないからちっとも広まらないぞ。

346 ：
これからの時代は Go! だ

347 ：
0が偽でそれ以外が真とか気持ち悪すぎ

348 ：
なんで？
0と3が偽とかのほうが気持ち悪くないか？

349 ：
真偽値はtrue/falseだけにしてくれ、数値まで真偽値扱いするなということでしょ。
自分もある程度はそう思うから、if (i)ではなくif (i == 0)って書く、iが数値型なら。

350 ：
Cが生まれた時代にはCにとっては実に合理的だったと思うけど
CPUにとってのゼロの意味も偽だし

351 ：
だいたい筋肉脳アメリカ人がつくったものはどれも大味すぎる

352 ：
普通にboolのある言語を先に学んだ人には
C/C++のif（）は気持ち悪いんだわ

353 ：
でっていう

354 ：
気持ち悪いなら
他人の作成したソースコードを読まなければよい

355 ：
整数型を真偽値に変換するときに0以外を真
真偽型を整数値に変換するときに真が1で偽が0
ポインタ型を真偽値に変換するときにヌル以外を真
とすると決まっているだけで
C++のboolもCの暗黙の真偽型も真と偽の二つの値しかとらない
暗黙の型変換が気持ち悪いのは同意

356 ：
boolのある言語から入ったけど、Cの真偽の判定は
リーズナブルだと思う
特に p をポインタとして　if(p) という書き方は美しくて好き

357 ：
lintっていうツールがあってだな
まぁ、美しいのは認めるが

358 ：
http://yosefk.com/c++fqa/fqa.html

359 ：
0かそれ以外で真偽を判定するのは
cだからじゃなくてマシン語がそうだからじゃないの?

360 ：
もともと仕様がそうなった理由は実装の都合かもしれないが、
実装依存じゃなくて現に言語仕様で決まっている以上は「Cだから」だ

361 ：
そもそも、ZEROは数じゃないってことじゃないの?
例えば
ここに、「りんご」が0個あります
この「りんご」は「りんご」ですか?
って事

362 ：
>>356
ぼくも(´・ω・｀)

363 ：
349のifでわざわざ0と比較しちゃう書き方はアセンブリ見ると無駄が増えてたと思う(vc)
油断は禁物だ

364 ：
>>363
普通は最適化で全く同じ扱いになるもんだが。

365 ：
なるもんだがだよね

366 ：
C++関連スレの多くが2008年キックオフか．．．。　当時は活気があったんだろうな。　ここ2年ぐらいで凋落の坂を下ったというわけか？

367 ：
C++11でnullptrが新設されたから0の問題は解決しただろ

368 ：
>>366
2ch全体がね。

369 ：
凋落してるのは2chの方だな

370 ：


自身が聞いた情報によると、もうじき中国はバブルがはじけて昔の貧乏な中国に戻るんだぜ
もう経済は破綻してて、取り戻すのは無理なんだそうだな

その世界ではやたら有名な政府関係者筋から聞いた確かな情報だな
まあお前ら頭の良い連中には、今さらなくらいのネタだ、
お前らからすればもう常識的なくらいの知識だろうぜ





371 ：
イテレータなんかを使うとポインタを上手く手なずけてる快感があるな。
C++にはまり込むと廃人になりそうだ。
複雑さの背景には機械の不条理さを手なずけるための工夫があるんだな。

372 ：
C++11はAutoがやっと来てくれたなって感じ

373 ：
foreachはまだ使えないの？

374 ：
君が決断すれば使えるよ

375 ：


376 ：
template <int N> struct Factorial {
enum { value = N * Factorial<N - 1>::value };
};
template <> struct Factorial<0> {
enum { value = 1 };
};

377 ：
>>373
int a[] = {1, 2, 3};
for (int x : a)
{
std::cout << x << std::endl;
}
名称はrange-based for文。
もうVC++でもg++でも使える。

378 ：
質問した人だけど
ありがとう
VC++2008じゃだめっぽい

379 ：
Cから離れるほど存在意義を失う。

380 ：
凋落（ちょうらく）

381 ：
C++はクラスと仮想関数の実装でやめておけば良い言語だった
ガベージコレクションを持たず、デストラクタが必要なこと自体は否定しない
しかしその状態で例外を実装したのが言語として終わった

382 ：
>>381
例外の何が問題なの？

383 ：
template も問題
boost みたいなまともな標準クラスライブラリが無かったのも問題

384 ：
STL は無視でつか？

385 ：
WTL / ATL はともかく STL のどこがまともなんだよ！

386 ：
>>383
標準とかいわれなければ覚えようとしないダメな子なんですね、よくわかります

387 ：
>>383
「〜が問題」とかじゃなくてさ、技術的な問題点を具体的に挙げようよ。

388 ：
デストラクタがあるからこそ例外が生きるんじゃないか

389 ：
RAIIでつね
確かに確かに

390 ：
GCもデストラクタもなしで例外導入されたらそれこそ問題w
何も分かっちゃいねえ

391 ：
例外実装したのならfinalyは必須
try〜catchの仕様もウンコだし、C++は欠陥言語と言わざるを得ない

392 ：
RAIIラッパーを書くのは確かにだるい。
スコープガードの技法で楽にはなったけど、
なんか直感的じゃないようなそうでもないような。
まあ、いまさらほしい機能でもないや＞finally

393 ：
デストラクタがあればfinallyなんて大体不要

394 ：
デストラクタのない欠陥言語だと
finallyの中にグダグダと泥臭い記述をするんだよ

395 ：
例外キャッチもせず、関数の初めでnew、終わりでdelete、
しかもnewの戻り値がNULLでないかチェックしてるアホコードを書く
C上がりの低脳PGが未だに大勢いる
当然メモリリーク起きまくりでまともに動きゃしないが、書いた当人は
「おかしい、ちゃんとnewとdeleteは対にしてるしエラーチェックもしてるのに」
とか言いながらトンチンカンなデバッグを何日もやっている
C++がなまじCの知識だけでもそこそこ書けてしまうせいで
大量の地雷コードが作られてしまった

396 ：
Hoge *h = NULL;
h = new Hoge;
if(!h) return 0;
...
delete h;
return 1;
なら例外拾わなくても安全

397 ：
>>396
えっ？

398 ：
>>396で問題になるケースってなんだ
operator newがbad_alloc以外を投げる場合とか？

399 ：
new(nothrow)で押し通すのも一つの哲学

400 ：
>>398
…の所で何らかの例外が発生した時

401 ：
>>400
なるほど・・・

402 ：
スマポ行っとけ

403 ：
メモリリークの危険があるからC++は駄目という主張は多いが、それくらいカバーできないで
プログラマ名乗るのもおこがましいのでは？

404 ：
>>403
個人の話ならその通り、というか、その人の自由。
会社では、そういう問題ではない。

405 ：
技術屋としてはC++を使いこなしたいと思わんかねえ

406 ：
立場によって意見も異なるって事でしょ。
結果として、要求を満たすモノを作れれば、個人のスキルなんか気にしないし、言語なんかなおさら何でも良いのが会社。

407 ：
ただ動きゃいいソフトとパフォーマンスが必要なソフトがある。
つか技術者の技術力が無くなったら国力低下だぞ

408 ：
だから、要件を満たせばって言ってるでしょ。
何で、ただ動くソフトとパフォーマンスが必用なソフトが引き合いになるんだよ。
パフォーマンスが要件にあるなら、当然満たす必要があるわけだが、それは技術力とは関係無い。
結果が出せるかどうか、それが全て。

409 ：
まあ、結果をだせるやつが技術力のあるやつとも言えるよな
結果も出せないで、技術力云々言うやつは論外だが、結構多いので困る

410 ：
>>407
もう手遅れ

411 ：
ぬるぽ

412 ：
技術力w
こんなものバズワード以外のなんだ？

413 ：
>>405
中二病の高校生か大学生ぐらいのもん

414 ：
ところが世の中のメジャーなアプリは殆どC++で実装されているというのが現実
Javaや.netでさえｗ
まあITドカタ君たちには無理だし必要ないから手を出さないほうがいいよ

415 ：
C++で組まなきゃ最新のPCでも反応は鈍いしGUIはショボいし無意味な飾りは多いし
イライラするソフトしか作れん

416 ：
受注あるの？

417 ：
C++抜きで大規模なシステムを組むのは難しい

418 ：
そういや、同じくcの拡張であるObjective-cはどんな印象をもっている？

419 ：
inline Smalltalk を書ける c/c++ なんだけど、Smalltalk の印象ってこと？

420 ：
Objective-Cはアップルの完全な管理下にあるという印象

421 ：
管理下っていっても結局clangでしょ
管理してんのは上っ面だけ

422 ：
Interface欲しい
イディオムで再現じゃなくてちゃんとサポートしてほしい

423 ：
Herb Sutter氏の語る現代的C++プログラミングの基本
http://www.infoq.com/jp/news/2014/10/modern-cpp-essentials

424 ：
「<<」 ってなんか恥ずかしくないか。
「オブジェクト指向言語だぜメッセージパッシングだぜ既存の言語とは違うぜー」
と鼻息荒くしていたころの厨二病的な気負いを感じる。
結局後続のオブジェクト指向言語は Java　も C# もそんなことやってなくて、
C言語の次にオブジェクト指向やろうという連中の多数がC++じゃなくて
そっちへ行っちゃった今となってはなんかこっけいなだけに見える。

425 ：
言語仕様が難しければ難しいほど良いというところはあるだろうな。
「関数型が流行ってる？じゃあ c++ にも入れよう！」みたいな感じで入れてる印象。
c++ にできないことがあってはならない！ってなところが異常な肥大化を生んでる。

426 ：
>>424
というより単にオペレータオーバーロードできまっせ！
うちはこんなんできまっせ！
ってだけのことだと思う

427 ：
サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート

428 ：
C++はパチンコにのめり込むようなもんや。博打に手だすのはやめときなはれ。

禿が死なん限り、簡略化されん

429 ：
最新の言語機能でドヤ顔したい奴を集めてしまう言語。
linus が c++ を嫌がる一番の理由。

430 ：
俺がc++じゃなければダメな理由はRAIIの使い勝手の良さの一点のみ。
文法なんて何でもいいから、RAIIさえ実現出来れば今すぐCメインにするわ。

431 ：
例外が絡まなければそんな複雑な話じゃないだろ。
結局例外が欲しいんだろ？

432 ：
例外はいらない。
例え例外が無くてもメモリリークするようなコードを書く奴が多いから困ってる。
そう、そんな難しいことではないのにね。
だからRAIIを半強制してる。

433 ：
それ強制してもリークしてるってことじゃん。
そういう奴はメモリがリークしなくてもどうせ他の資源をリークさせるようなコード書くだろうし、
言語で解決できる問題じゃない。

434 ：
その通り。
完全解決しようなんて思ってない。
頻度の問題。

435 ：
なんで半強制じゃなく完全強制しないの？
頻度の問題とか言ってる場合じゃないと思うが

436 ：
ん？ちょっと論点が変わったね？
完全強制しても頻度が減るくらいで、完全解決できないからだよ。
何事も費用対効果と言うものがあるし。

437 ：
newやmallocやopen等のリソース獲得コードをアプリ上位レベルで書くのを禁止すれば完全解決できるんだがね
リソース獲得をするのは下位ライブラリに閉じ込めてそれは然るべき人間が書いてしっかりデバッグする

438 ：
きちんとロジック隠蔽できればnew/delete使っても問題ないと思う。
そのためのオブジェクト思考だし。
スマポ推奨する前に開発方法の意識を高めることの方が先だろと言いたい。

439 ：
そうしてるけど？

440 ：
だだ、下位レベルとは言え、その辺の事を徹底するのはコストがかかるんだよ。
俺一人で見切れる規模でもないし。

441 ：
頻度の問題と言われても
コンストラクタ、デストラクタ用意した言語使うだけでそんな減るもんかね。
まあ経験的な話なんでなんとも言いようがないけど。

442 ：
>>441
ぶっちゃけコンストラクタはいらない。
デストラクタだけ必要。

443 ：
>>442
コンストラクタ不要論ｗｗｗ

444 ：
あー、わかるわー
デストラクタだけはC言語の範囲だと絶対実現できないもんなー
コンストラクタやクラスに近いものは作れるけど、実用的なデストラクタはムリ

445 ：
そこはコストをかけてプロを採用すべき

446 ：
c++と同じくらい万能でc++での速さを残して短所を改良した言語ﾏﾀﾞｰ？

447 ：
boostブームのときは静観してたが
c++11はけっこういいんじゃないかと思った
VSもサポートしてるし

448 ：
標準ヒープを当たり前に使うライブラリを作るやつが許せない
C++使わずGC言語使ってろよバカと思う
標準ライブラリも大抵は置き換え可能とはいえヒープありきのデザイン多すぎ

449 ：
Erlang最強ですねわかります

450 ：
Elixir を使え

451 ：
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

6NO57

452 ：2018/07/05
EED

WPF(.NET4.x, .NET Core) GUIプログラミング Part23
CORBAなら俺に聞け
Access VBA 質問スレ Part2
datファイルを共有するP2Pソフト o2on 17dat
スレ立てるまでもない質問はここで 148匹目
0からの、超初心者C++相談室
おまいらはディープラーニングの検定試験受けるの？
C＃で仕事ある？
スレ立てるまでもない質問はここで 148匹目
Ruby 初心者スレッド Part 65
--------------------
【バーチャルYouTuber】ロボ子さんアンチスレ#2【ホロライブ/hololive】
【山梨】東京から来たツーリングの男性が転倒し背骨を折るなどの重傷　山梨来県自粛要請の中 ★2 [nita★]
三重県の自転車乗り/自転車店/自転車道 総合 10
衝撃を受けた“裏切りキャラ”といえば？ ジャンプ作品やガンダムシリーズに「ショック」の声！“敵から味方”になる裏切りも
【アッキード/森友】消された「安倍昭恵」文書　財務省4000枚の森友文書公開も無意味◆6★1683
山口県　農協人　農業人
【価格も】コスパ高い日本酒【味のうち】
待機児童はその存在を抹消しますアベノミクス
高速バス乗ってたら韓国人の女が友達と隣同士で座りたいから席かわってくれとか言ってきたんだけど、お前らならどうする？ [998357762]
●女子フットサル●興味ある人集まれ〜 ●
石田純一を見るとジェラシーで血圧上がる
こんなリンゴ・スターは嫌だ！！
長野県の文房具店
投資・運用してる公務員のスレ★２
Snow Man・SixTONES 総合雑談スレ
邦楽厨にうける洋楽ってなんだと思う？
無双OROCHI総合 429K.O.COUNT
ホワイトキー関西51・上東弘幸　うえひがし　ひろゆき　(上田弘幸・上東弘介)情報専用スレ
【横浜Fﾏﾘﾉｽ】三ツ沢球技場のいいところ【横浜FC】
東北地方のうまいたこ焼きは？
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼