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

■ このスレッドは過去ログ倉庫に格納されています
2008/10/10(金) 09:13:53
C++の問題点について語るスレです

C++ってなんであんなに肥大化しちゃったの？
http://pc11.2ch.net/test/read.cgi/tech/1219902495/
66デフォルトの名無しさん
垢版 |
2008/10/16(木) 18:38:55
結論から言うと、演算子オーバーロードはＳＴＬ向けの関数オブジェクト作るためだけに使え、
ということだな。
2008/10/16(木) 19:47:53
, || && は boost::spirit で活躍しているよ。
2008/10/16(木) 21:27:42
>>66
なぜそれが結論なのかが知りたいのですけど?
一体何が問題なのですか?
2008/10/16(木) 22:10:53
std::cout << "banana" << count << std::endl;

(ノ ﾟДﾟ)ノ　＝＝＝＝　┻━━┻
2008/10/16(木) 23:04:10
コンテナ継承させてよぅ
2008/10/16(木) 23:24:11
ただの質問スレだったら、protected継承でいいじゃないって答えるところだな。
2008/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のどちらが先に評価されるか分からない(処理系依存)。

分かりにくいバグの元になる、コードの可搬性を損なう、などの理由から
&&や||のオーバーロードは推奨されない。
2008/10/17(金) 00:22:41
>>72
つまり、&&オーバーロードは、+等のオーバーロードとは違う解釈で実行されるってことなの?
それなら、大きな問題だなぁ...
2008/10/17(金) 00:26:31
>>組み込み型に対する&&や||は短絡といって、

それと同じ構造にすればいいだろ
2008/10/17(金) 00:29:42
>>74
C#とかそれを目指している。
C++でもBoost.Lambdaは頑張った。

あと今から同じ構造になる仕組みをC++に持ち込んだとしても、
「互換性のため」現状の&&と||もそのまま残ること間違いない。
2008/10/17(金) 01:43:05
比較的どうでもいい豆知識だな
2008/10/17(金) 01:51:46
遅延評価の考え方がどうでもいい豆知識っすか
Cにどっぷりはまるとそうなっちゃうのね
2008/10/17(金) 02:33:00
短絡評価 short-circuit evaluation と遅延評価 lazy evaluation はまったくの別物だぞ
遅延評価は、必要になるまで変数の値の計算を先延ばしにするHaskellのアレだ
2008/10/17(金) 02:37:48
同じ様なもんだろ
右オペランドを遅延評価することを短絡評価という
80デフォルトの名無しさん
垢版 |
2008/10/17(金) 02:44:31
じゃあ遅漏評価は？
2008/10/17(金) 03:07:21
>79
遅延評価はもっと広い意味の言葉だから混同するとややこしい。
2008/10/17(金) 08:55:24
>>64
何の指摘にもなってないよ
83デフォルトの名無しさん
垢版 |
2008/10/17(金) 09:10:07
オーバーロード関数のDLLが・・・
2008/10/17(金) 09:13:17
>>83
日本語でok
2008/10/17(金) 10:40:56
オーバーロードしたら&&が論理和どころか論理演算ですらある必要がないので、
通常と同じ動作にしたらいいじゃんという主張は無意味だろ。
2008/10/17(金) 11:07:09
演算子の元の意味と大きく異なるオーバーロードは駄目だろ
おまえは+が加算である必要が無いからって乗算にするのか？
2008/10/17(金) 12:04:19
＞ 演算子の元の意味と大きく異なるオーバーロードは駄目だろ

そこで << ですよ
2008/10/17(金) 12:10:38
>>72
良く分からんが
if ( b1 && b2 )
は
if ( b1.operator&&(b2) )
と等価じゃないの?
2008/10/17(金) 13:09:18
常識という眼鏡で僕達の世界はのぞけやしないのさ
夢を忘れた古いプログラマーたちよ

アンドじゃないアンドじゃない
素敵な世界
2008/10/17(金) 15:03:38
>>88
operator&&() が my_bool のメンバならね。
でも
    bool operator&&(const my_bool& a, const my_bool& b)
かも知れない。
更に、b1 が左辺値ではなく my_bool を戻す式だったとき、
やっぱり b2 とどっちが先に評価されるかは判らない。
2008/10/17(金) 16:06:02
>>90
引数の評価順を重要視する意味がよくわからん
引数の時点で、真偽がわかったとしても関数から抜け出す手段は無いとおもうが?

b1 && b2 && b3
の式の場合
operator&&(operator&&(b1, b2), b3)
となって、operator&&(b1, b2)が偽の場合でも、一番外側のoperator&&()が実行されるから嫌だって事なら、ちょっとだけ理解できるかもしれないが
だからと言って、C++の欠陥だと大声で言うようなものでも無いと思うのですが
2008/10/17(金) 16:52:03
>>91
短絡評価のメリットが解らない、ってこと？
2008/10/17(金) 17:17:31
>>92
短絡評価のメリットを受けられるほど長い論理式を使うつもりなのですか?
それとも、短絡評価のメリットを受けられるほどのif文の山を築く気ですか?
2008/10/17(金) 17:41:19
話がまた斜め上の方向に捩れてるな

>>91
if 式 文
で式の内容如何によらず文が評価されていいと思ってるのか？
遅延評価無しではif文を関数化することは出来ない
だから禿も?:はoperator化していない
にもかかわらず、同様の機能を持っている&&や||をoperator化しているのが
マヌケだという話だろ

>>93
言語仕様の問題をプログラミングスタイルの方向に摩り替えたい人発見
2008/10/17(金) 18:00:57
バグの原因は小さいものだから
大きな問題ではないと考えるのも無理はない
2008/10/17(金) 18:05:33
INT i=1,j=1; //なんかint的なクラスだと思いね

i++ || j++;
cout << i << "," << j;

||がオーバーロードされていなければ「2,1」が表示される
されていれば「2,2」が表示される



open(file) && abort();

&&がオーバーロードされていなければ、ファイルオープンに成功すれば処理が続行される
されていればファイルオープンに成功したのに異常終了する
2008/10/17(金) 18:32:16
>>94
論理式は論理式だろ?
if文や三項演算子とは関係ないんじゃない?

>>96
むしろ、その使い方が、言語仕様の悪用だと思います
2008/10/17(金) 18:46:18
>>97
いや、ショートサーキットの&&や||はifの変種みたいなもんだぞ
C/C++に引きこもっているうちは分からないかもしれないが、
他の言語もやってみれば分かるよ
2008/10/17(金) 18:52:24
つーか短絡評価しないなら&や|だけでいい
何のためにわざわざ&&や||が用意されてると思ってるんだ
2008/10/17(金) 18:54:39
>>99
それもちょっと違うけどな
1 && 2は真だけど 1 & 2は0だし
2008/10/17(金) 18:55:39
そうだな
ごめんアホなこと言った
2008/10/17(金) 19:44:48
>>98
論理式が返すのは、論理値だろ
論理式の処理過程を期待してプログラムするってのは、真値が特定の値である事を期待してプログラムするのと同じじゃん
2008/10/17(金) 19:50:03
>>102
そうだよ、一部ではもはやただの論理式ではなく制御構造と見なされているということ。
C++ではあまり見ないけど、PerlとかでHogeHoge or dieとか。
2008/10/17(金) 19:50:39
>>102
＞論理式の処理過程を期待してプログラムする

「期待」じゃなくてC/C++は「仕様で」「明確に」「わざわざ」評価順を
定義しているわけだが
&& || に関してはな
何の意味も無くそんな仕様にしてると思ってんの？

ま、&&や||は論理演算、bool代数だよな？そこはその通りだ。
フローコントロールもセマンティクスも変えちまう
オーバーロードなんてもってのほかだよな？
2008/10/17(金) 19:59:18
bool banana;

if(!banana)
{
// ↑気持ち悪いねこれ。
}
2008/10/17(金) 20:01:54
if(true != banana)
if(false == banana)

好きなほうを選べ
2008/10/17(金) 20:02:26
VB.NETではVBには無かった短略評価の
AndAlso OrElse という（キモい）演算子が追加されているのだが
その意味も分からないんだろうねえ
2008/10/17(金) 20:10:39
>>104
言ってることがわからない
&&や||をオーバーロードできるように定義しているのも「仕様」なんじゃないの?
2008/10/17(金) 20:12:51
>>108
だから、その仕様が不整合で良くないっつー話をしてるんだろ
言うまでも無く後から突っ込んだオーバーロードの仕様がマズい
2008/10/17(金) 20:19:03
&&や||をオーバーロードの場合はコンパイラが短絡すればいいだけだろ
2008/10/17(金) 20:27:57
何だそれ
互換性が無くなってさらにカオスになるだけじゃねえか
2008/10/17(金) 20:31:27
&&と||の意味がわかんねー奴はC++厨気取りたいんなら
More Effective C++ぐらい嫁
2008/10/17(金) 20:36:52
.front()も.begin()も同じで良いジャン
なんで違うの
2008/10/17(金) 20:48:12
>>113
hoge.front()は*hoge.begin()相当。
強いて言えば、beginからfrontは取り出せるが逆は一般にできないんでfrontがやや余計かな。
2008/10/17(金) 20:52:08
front取り忘れたのかね
2008/10/17(金) 21:20:33
map持っていて

<<でkeyを流し込んだら valueが返ってくるクラスはあり？
2008/10/17(金) 21:29:44
演算子でやる理由がわからん
2008/10/17(金) 21:46:28
>>116
[]演算子で標準装備してない？
まあこれはkeyを持ってなかったらvalueにはデフォルトコンストラクタで生成
した値が代入されてしまうんだけど
2008/10/17(金) 21:51:59
[]だとポインタのとき面倒じゃね？
2008/10/17(金) 21:54:05
value = (*hogemap)[key]
でおけ
2008/10/17(金) 21:58:28
あえて operator()
2008/10/17(金) 22:39:11
ttp://homepage2.nifty.com/well/Operator.html#arrow_ast



なんでもあり
2008/10/17(金) 23:04:00
>>119
いやポインタに対して使うときは全部だろ
2008/10/18(土) 00:55:05
C++のIDEに自動的にヘッダやnamespaceを宣言してくれる奴って何かあります？
Javaとかだと適当にクラス使ってもクラスパスから候補探してくれるのがメジャーなIDEの基本機能にある。
2008/10/18(土) 05:16:34
>>124
ゆとりは黙ってろよ(笑)
そんな余計な機能はIDEには要らない
2008/10/18(土) 05:38:24
自動的にヘッダを追加するようなIDEは怖くて使えません
2008/10/18(土) 13:39:49
さすが生産性の無さでユーザーがみるみる減っている言語だけはあるｗ
2008/10/18(土) 13:56:13
>>124
C++のヘッダのincludeは単なるプリプロセッサ命令で、やってることは
原始的なコピペ
Javaは自己記述的なjarやclassからシンボルをインポートしてるわけだ

C++でそういうことをやるのは技術的に不可能ではないだろうが
向いているとは思えんな
現代的なIDEなどが出るよりはるか以前に作られた化石言語なのだから仕方が無い
2008/10/18(土) 14:06:23
C++はIDEととことん相性悪いからな
まるでIDEを妨害しようとしているかのような仕様

VSやBuilderやCDTはマジ頑張ってると思うのですよ
頭が下がる
2008/10/18(土) 21:29:58
C++を有難がって使ってる奴なんているの？
居たとしたらちょっと馬鹿すぎる
2008/10/18(土) 21:38:06
文句なしの代替が無いから使っているだけだよ。
2008/10/18(土) 22:40:11
有難がって使うプログラミング言語なんてないだろ。
2008/10/18(土) 22:51:52
>>130
C#がネイティブ初めから吐いてくれたらそっちに移行したいんだが
仕方ないからC++を使ってる

つーかC#プログラマ恵まれ過ぎだろ・・・
2008/10/18(土) 22:53:30
C++が一番簡単だから使ってる
2008/10/18(土) 22:59:07
結局、
2008/10/18(土) 23:00:16
結局、このスレにC++信者なんて居なかったってオチか
2008/10/19(日) 01:23:10
>>105
↑頭悪いねこれ。
2008/10/19(日) 14:06:06
C++が最高だと思って使ってる奴はいないだろ。
ただ分かってない上司やクライアントがいるからC++の仕事もあるってだけだ。
本当はCで十分だったり、C#やJavaの方が効率良かったりするんだが。
2008/10/19(日) 14:12:04
C#やJavaをフロントエンドにして、
OS依存部分や、処理が思い部分を
C言語で書くスタイルがベストだな。

既にOracleがそうだし、CADもそういうのがある。
2008/10/19(日) 14:23:15
C++はプログラム初級〜中級者向けのおもちゃとしてはそこそこ面白い
だが普通はすぐに暗黒面に気付いて使うのを辞めるor仕事で仕方なく使うだけだ
2008/10/19(日) 14:41:12
その通り過ぎて何も言えねえ…
良い代替言語があれば良いんだけどね
2008/10/19(日) 14:53:48
D言語がふらふらしてなければなｗ
創始者が「仕様変えるぞー」を未だに自粛しないからこまったものだ。
2008/10/19(日) 16:11:15
まあ暗黒面に気付かないうちはまだまだ初心者ってことだ
それに気付いた時にはバッドノウハウばかりで他言語に応用が効かないのも悔しいところだ
2008/10/19(日) 16:19:28
Plan9(笑)
D言語(笑)
2008/10/19(日) 16:37:25
バッドノウハウを追求するのは楽しい
しかしチームでやる仕事ではゴメンだね
2008/10/22(水) 11:30:38
クライアントから例外もテンプレートも（わからないから）使わないで欲しいって言われた
周辺環境もある意味では言語の問題点に含まれると思う
特にC++の場合、ひとによってスキルの差がありすぎ
せっかくのリソースが活かせないことが多い

まあ割の良い仕事だから我慢するけど、これならCの方が開発効率良いよorz
2008/10/22(水) 17:05:15
Cの方が開発効率良い、に関しては、
だったらクラスも何も使わないでC同然に書けばいいじゃないと思う。
2008/10/22(水) 17:14:26
>>146
クラスがあるだけで private とクラスの名前空間があるから
かなり精神的に楽になる。依然マクロの脅威はあるけど。
2008/10/22(水) 18:05:19
>>147
それならCでいい、というかCのがいいだろ
malloc()の戻り値などをいちいちキャストする必要は無いし
Cリンケージのためにいちいちextern "C"などと書く必要も無い
2008/10/22(水) 19:03:52
>>149
147でないけど

キャストは new の仕様を促すからそのほうがいいんじゃない。new の方が楽で型安全だし。

extern "C" はCとリンクする部分だけでいいよ。普通の C のライブラリだって extern "C" 使ってるし。
extern "C" を使わないほうが型安全だし。
2008/10/22(水) 19:18:08
>>150
newは例外まみれで鬱陶しい別の問題を引き起こすだろ
ただの関数形式のアロケータなら差し替えるのも簡単だ
C++をC++らしく使わないという仮定の話をしているようだから
それぐらいならCの方がいいと言ってるんだよ

クラスすら使わないC++で提供される付加価値よりは
グダグダなABIだの、さりげなく仕込まれる例外対策だののほうがずっと鬱陶しい
2008/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);
}
いや、これもずっと鬱陶しい「さりげなく仕込まれる例外対策」の内というならそれまでだけど。
2008/10/23(木) 00:24:04
bad_allocが嫌ならnothrowつきのnewを使えばいいじゃない

ただ、例外を使わないようにするとどうせNULLチェックをサボる奴が出てくるので
むしろ有害だと思うけどな
2008/10/23(木) 02:02:52
NULLチェックをサボるために例外を使うってことは、newする部分をまとめてtryに入れるんだろうけど、
スマートポインタかGCでもない限り、メモリリークの危険性がある。
STLで用意されてるauto_ptrはSTLコンテナに食わせられない糞仕様。
2008/10/23(木) 08:09:11
CAutoPtr
2008/10/23(木) 11:08:44
>>154
まだ過去の話してんのか
std::tr1::smart_ptrは今では当然のように使う
2008/10/23(木) 11:46:55
std::tr1::shared_ptrかboost::smart_ptrのどっちかと間違えてるんだと思うが
どっちにしろどうしても必要な所で最低限の使用にしないと重すぎて酷いことになるからなぁ
auto_ptrはそこそこ軽いから割と気軽に使える

まあ、本当は生ポインタが一番いいんだけどな
プログラマが楽をするためだけにスマポの莫大なオーバーヘッドを持ち込むのは感心できない
2008/10/23(木) 12:17:44
プログラマに苦労を強いると、バグの発生率が跳ね上がるでしょ。
多くの状況ではオーバーヘッドよりバグの方が深刻な問題になるんだから、楽はすべきだと思うけど。
2008/10/23(木) 13:12:15
C + Boehm GCでいいやん
スマポなんかより便利だし
2008/10/23(木) 13:21:50
>>157
boost::smart_ptr なんて存在しない。
どっちも shared_ptr。

あとオーバーヘッドなんて大したことないぞ。
ポインタに参照カウントの分の整数がついて回るだけ。
ポインタアクセス時は通常のポインタとほぼ同等
（レジスタ割り付けが多少阻害されるかもしれんが）。
コピーやデストラクト時に参照カウントの増減でこれも一瞬。
2008/10/23(木) 19:05:25
boost::intrusive_ptr 方式のスマートポインタが好き。
2008/10/23(木) 20:50:24
UN*X では Objective-C が使えるから無理して C++ を使う必要は無いよね
2008/10/23(木) 21:02:12
>>162
極一部のUnix以外ではCが主流というオチ。
2008/10/23(木) 21:22:07
unixだとc++なんか有象無象とひとつ
2008/10/23(木) 21:28:01
>>154
ようやく次のC++0xで、コンテナに入れられるunique_ptrが入る。
参照カウントせずauto_ptrと全く同じオーバーヘッド。
まったくもって導入が遅すぎる。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況