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

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

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

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

**デフォルトの名無しさん** · 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

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

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

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

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

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

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

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

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

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

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

>>189
C99なら嘆かわしいことに出来てしまう

まあ、あんなものC言語じゃないけどな

**デフォルトの名無しさん** · 2008/11/03(月) 19:11:25

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

**デフォルトの名無しさん** · 2008/11/03(月) 21:30:24

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

**デフォルトの名無しさん** · 2008/11/03(月) 22:35:07

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

**デフォルトの名無しさん** · 2008/11/04(火) 00:23:34

Cに++した程度の言語だ
やばくて当たり前だっての

オブジェクト指向アセンブラに何処まで求めてるんだ?

**デフォルトの名無しさん** · 2008/11/04(火) 00:39:19

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

残念言語

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

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

**デフォルトの名無しさん** · 2008/11/04(火) 09:33:16

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

**デフォルトの名無しさん** · 2008/11/05(水) 18:03:54

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

**デフォルトの名無しさん** · 2008/11/05(水) 18:33:56

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

**デフォルトの名無しさん** · 2008/11/06(木) 16:48:48

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

**デフォルトの名無しさん** · 2008/11/06(木) 18:08:29

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

**デフォルトの名無しさん** · 2008/11/06(木) 19:33:21

const_cast

**デフォルトの名無しさん** · 2008/11/06(木) 20:24:16

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

**デフォルトの名無しさん** · 2008/11/06(木) 21:22:36

・constなんてconst_castや普通のキャストで誰でも簡単に外せる
・constを外さなくたってmutableメンバがあれば変更し放題
・deleteに対してconstは全く無力

何かを安全にするつもりでconstを使ってるなら、それは時間の無駄です
constは何も守ってくれません

**デフォルトの名無しさん** · 2008/11/06(木) 21:45:34

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

**デフォルトの名無しさん** · 2008/11/06(木) 21:46:39

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

**デフォルトの名無しさん** · 2008/11/06(木) 21:51:57

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

**デフォルトの名無しさん** · 2008/11/06(木) 21:58:17

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

**デフォルトの名無しさん** · 2008/11/06(木) 22:04:48

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

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

EffectiveSTLの22番だな

**デフォルトの名無しさん** · 2008/11/07(金) 03:43:36

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

**デフォルトの名無しさん** · 2008/11/07(金) 09:35:55

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

**204** · 2008/11/07(金) 12:14:46

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

**デフォルトの名無しさん** · 2008/11/07(金) 16:23:46

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

**デフォルトの名無しさん** · 2008/11/07(金) 17:01:39

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

**デフォルトの名無しさん** · 2008/11/07(金) 17:05:50

また始まった
ぼくはそんなつかいかたしないからC++はわるくないんだい！！

なんか本気で言ってそうでかわいそうになる

**デフォルトの名無しさん** · 2008/11/07(金) 17:29:08

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

**デフォルトの名無しさん** · 2008/11/07(金) 17:53:25

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

**デフォルトの名無しさん** · 2008/11/07(金) 17:54:41

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

**デフォルトの名無しさん** · 2008/11/07(金) 18:12:17

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

**デフォルトの名無しさん** · 2008/11/07(金) 20:36:53

const_castはどう考えても内容を変更しないのになぜか非定数を要求するAPIのためのもの。

Motifやってた頃はお世話になりました。

**デフォルトの名無しさん** · 2008/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との互換性は無くなったが。

**デフォルトの名無しさん** · 2008/11/07(金) 23:36:09

アホな事する奴がconst_castなんて律儀に書くわけないという

**デフォルトの名無しさん** · 2008/11/07(金) 23:42:36

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

**デフォルトの名無しさん** · 2008/11/08(土) 18:01:46

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

**デフォルトの名無しさん** · 2008/11/08(土) 18:40:10

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

**デフォルトの名無しさん** · 2008/11/08(土) 19:11:13

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

**デフォルトの名無しさん** · 2008/11/08(土) 22:32:08

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

**デフォルトの名無しさん** · 2008/11/08(土) 23:17:56

.NETみたいに

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

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

**デフォルトの名無しさん** · 2008/11/09(日) 16:31:19

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

**デフォルトの名無しさん** · 2008/11/09(日) 17:00:09

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

**デフォルトの名無しさん** · 2008/11/10(月) 08:50:37

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

**デフォルトの名無しさん** · 2008/11/10(月) 12:49:34

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

**デフォルトの名無しさん** · 2008/11/10(月) 14:23:58

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

**デフォルトの名無しさん** · 2008/11/10(月) 23:39:57

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

**デフォルトの名無しさん** · 2008/11/11(火) 03:31:15

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

**デフォルトの名無しさん** · 2008/11/11(火) 10:36:41

分の悪い取引だな

**デフォルトの名無しさん** · 2008/11/24(月) 12:51:07

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

**デフォルトの名無しさん** · 2008/11/24(月) 17:07:17

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

**デフォルトの名無しさん** · 2008/11/24(月) 20:46:57

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

**デフォルトの名無しさん** · 2008/11/25(火) 03:33:56

もう来るなよ。

**デフォルトの名無しさん** · 2008/11/25(火) 06:30:45

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