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

**デフォルトの名無しさん** · 2008/10/10(金) 09:13:53

C++の問題点について語るスレです

C++ってなんであんなに肥大化しちゃったの？
http://pc11.2ch.net/test/read.cgi/tech/1219902495/

**デフォルトの名無しさん** · 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と全く同じオーバーヘッド。
まったくもって導入が遅すぎる。

**デフォルトの名無しさん** · 2008/10/27(月) 19:09:41

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

**デフォルトの名無しさん** · 2008/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");
こうやって利用すればいいんでないの?

**デフォルトの名無しさん** · 2008/10/29(水) 13:34:53

>>167
言いたい事は分かるけど、コピーコンストラクター位はつけた方がいいと思うんだ

**デフォルトの名無しさん** · 2008/10/29(水) 13:46:13

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

**デフォルトの名無しさん** · 2008/10/29(水) 13:55:15

>>167
なんだそれ

vAlloc<char> str1(100);
なんてやるなら
char str1[100];
でいいだろ

そのクラスはそれ以上のものをそれは何も提供していないし
何の解決にもなっていない

**デフォルトの名無しさん** · 2008/10/29(水) 14:02:26

STLとかはAllocator差し替えられるけど
alloc()が例外投げること前提に作られてて
NULLチェックなんてしてるわけねーし

C++でデフォのnew捨てるってのは
事実上、標準を含む大半のライブラリを捨てるってこと

**デフォルトの名無しさん** · 2008/10/29(水) 14:03:41

>>170
何言ってるんだ?
君のコンパイラは、

char str1[strlen(hoge) + 1];

こんな使い方が出来るのか?

**デフォルトの名無しさん** · 2008/10/29(水) 14:05:16

>>172
ああ、いいたいことは分かった
alloca()っぽいことが出来るんだね

alloca()の代用にしかなってないけど

**デフォルトの名無しさん** · 2008/10/29(水) 14:09:13

コンストラクタやデストラクタが動くんだからalloca()の代用は言いすぎか

まあ、そういうことが言いたいんじゃなくて、newが使われるシナリオの
ごくごく一部しかカバーできていないだろ、といいたいんだよ

**デフォルトの名無しさん** · 2008/10/29(水) 14:41:56

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

**デフォルトの名無しさん** · 2008/10/29(水) 16:21:08

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

**デフォルトの名無しさん** · 2008/10/29(水) 16:50:22

>>176
newが例外をスローしないようにするのなら
vectorなんて使えないんじゃないのか

new_handlerの中でabort()でも呼ぶのならいいだろうけど、もっと悪いような

**デフォルトの名無しさん** · 2008/10/29(水) 17:37:38

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

**デフォルトの名無しさん** · 2008/10/29(水) 18:06:25

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

**デフォルトの名無しさん** · 2008/10/29(水) 19:09:35

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

**デフォルトの名無しさん** · 2008/10/29(水) 19:13:25

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

**デフォルトの名無しさん** · 2008/10/29(水) 19:39:56

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

**デフォルトの名無しさん** · 2008/10/30(木) 01:39:17

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

**デフォルトの名無しさん** · 2008/10/30(木) 09:41:16

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

**デフォルトの名無しさん** · 2008/10/30(木) 10:01:22

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

**デフォルトの名無しさん** · 2008/10/30(木) 13:05:43

どこ？

**デフォルトの名無しさん** · 2008/11/02(日) 04:11:41

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

**デフォルトの名無しさん** · 2008/11/02(日) 07:33:07

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