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

【信者】C++の問題点� ..

116:デフォルトの名無しさん
08/10/17 21:20:33
map持っていて

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

117:デフォルトの名無しさん
08/10/17 21:29:44
演算子でやる理由がわからん

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

119:デフォルトの名無しさん
08/10/17 21:51:59
[]だとポインタのとき面倒じゃね？

120:デフォルトの名無しさん
08/10/17 21:54:05
value = (*hogemap)[key]
でおけ

121:デフォルトの名無しさん
08/10/17 21:58:28
あえて operator()

122:デフォルトの名無しさん
08/10/17 22:39:11
URLﾘﾝｸ(homepage2.nifty.com)

なんでもあり

123:デフォルトの名無しさん
08/10/17 23:04:00
>>119
いやポインタに対して使うときは全部だろ

124:デフォルトの名無しさん
08/10/18 00:55:05
C++のIDEに自動的にヘッダやnamespaceを宣言してくれる奴って何かあります？
Javaとかだと適当にクラス使ってもクラスパスから候補探してくれるのがメジャーなIDEの基本機能にある。

125:デフォルトの名無しさん
08/10/18 05:16:34
>>124
ゆとりは黙ってろよ(笑)
そんな余計な機能はIDEには要らない

126:デフォルトの名無しさん
08/10/18 05:38:24
自動的にヘッダを追加するようなIDEは怖くて使えません

127:デフォルトの名無しさん
08/10/18 13:39:49
さすが生産性の無さでユーザーがみるみる減っている言語だけはあるｗ

128:デフォルトの名無しさん
08/10/18 13:56:13
>>124
C++のヘッダのincludeは単なるプリプロセッサ命令で、やってることは
原始的なコピペ
Javaは自己記述的なjarやclassからシンボルをインポートしてるわけだ

C++でそういうことをやるのは技術的に不可能ではないだろうが
向いているとは思えんな
現代的なIDEなどが出るよりはるか以前に作られた化石言語なのだから仕方が無い

129:デフォルトの名無しさん
08/10/18 14:06:23
C++はIDEととことん相性悪いからな
まるでIDEを妨害しようとしているかのような仕様

VSやBuilderやCDTはマジ頑張ってると思うのですよ
頭が下がる

130:デフォルトの名無しさん
08/10/18 21:29:58
C++を有難がって使ってる奴なんているの？
居たとしたらちょっと馬鹿すぎる

131:デフォルトの名無しさん
08/10/18 21:38:06
文句なしの代替が無いから使っているだけだよ。

132:デフォルトの名無しさん
08/10/18 22:40:11
有難がって使うプログラミング言語なんてないだろ。

133:デフォルトの名無しさん
08/10/18 22:51:52
>>130
C#がネイティブ初めから吐いてくれたらそっちに移行したいんだが
仕方ないからC++を使ってる

つーかC#プログラマ恵まれ過ぎだろ・・・

134:デフォルトの名無しさん
08/10/18 22:53:30
C++が一番簡単だから使ってる

135:デフォルトの名無しさん
08/10/18 22:59:07
結局、

136:デフォルトの名無しさん
08/10/18 23:00:16
結局、このスレにC++信者なんて居なかったってオチか

137:デフォルトの名無しさん
08/10/19 01:23:10
>>105
↑頭悪いねこれ。

138:デフォルトの名無しさん
08/10/19 14:06:06
C++が最高だと思って使ってる奴はいないだろ。
ただ分かってない上司やクライアントがいるからC++の仕事もあるってだけだ。
本当はCで十分だったり、C#やJavaの方が効率良かったりするんだが。

139:デフォルトの名無しさん
08/10/19 14:12:04
C#やJavaをフロントエンドにして、
OS依存部分や、処理が思い部分を
C言語で書くスタイルがベストだな。

既にOracleがそうだし、CADもそういうのがある。

140:デフォルトの名無しさん
08/10/19 14:23:15
C++はプログラム初級～中級者向けのおもちゃとしてはそこそこ面白い
だが普通はすぐに暗黒面に気付いて使うのを辞めるor仕事で仕方なく使うだけだ

141:デフォルトの名無しさん
08/10/19 14:41:12
その通り過ぎて何も言えねえ…
良い代替言語があれば良いんだけどね

142:デフォルトの名無しさん
08/10/19 14:53:48
D言語がふらふらしてなければなｗ
創始者が「仕様変えるぞー」を未だに自粛しないからこまったものだ。

143:デフォルトの名無しさん
08/10/19 16:11:15
まあ暗黒面に気付かないうちはまだまだ初心者ってことだ
それに気付いた時にはバッドノウハウばかりで他言語に応用が効かないのも悔しいところだ

144:デフォルトの名無しさん
08/10/19 16:19:28
Plan9(笑)
D言語(笑)

145:デフォルトの名無しさん
08/10/19 16:37:25
バッドノウハウを追求するのは楽しい
しかしチームでやる仕事ではゴメンだね

146:デフォルトの名無しさん
08/10/22 11:30:38
クライアントから例外もテンプレートも（わからないから）使わないで欲しいって言われた
周辺環境もある意味では言語の問題点に含まれると思う
特にC++の場合、ひとによってスキルの差がありすぎ
せっかくのリソースが活かせないことが多い

まあ割の良い仕事だから我慢するけど、これならCの方が開発効率良いよorz

147:デフォルトの名無しさん
08/10/22 17:05:15
Cの方が開発効率良い、に関しては、
だったらクラスも何も使わないでC同然に書けばいいじゃないと思う。

148:デフォルトの名無しさん
08/10/22 17:14:26
>>146
クラスがあるだけで private とクラスの名前空間があるから
かなり精神的に楽になる。依然マクロの脅威はあるけど。

149:デフォルトの名無しさん
08/10/22 18:05:19
>>147
それならCでいい、というかCのがいいだろ
malloc()の戻り値などをいちいちキャストする必要は無いし
Cリンケージのためにいちいちextern "C"などと書く必要も無い

150:デフォルトの名無しさん
08/10/22 19:03:52
>>149
147でないけど

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

extern "C" はCとリンクする部分だけでいいよ。普通の C のライブラリだって extern "C" 使ってるし。
extern "C" を使わないほうが型安全だし。

151:デフォルトの名無しさん
08/10/22 19:18:08
>>150
newは例外まみれで鬱陶しい別の問題を引き起こすだろ
ただの関数形式のアロケータなら差し替えるのも簡単だ
C++をC++らしく使わないという仮定の話をしているようだから
それぐらいならCの方がいいと言ってるんだよ

クラスすら使わないC++で提供される付加価値よりは
グダグダなABIだの、さりげなく仕込まれる例外対策だののほうがずっと鬱陶しい

152:デフォルトの名無しさん
08/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);
}
いや、これもずっと鬱陶しい「さりげなく仕込まれる例外対策」の内というならそれまでだけど。

153:デフォルトの名無しさん
08/10/23 00:24:04
bad_allocが嫌ならnothrowつきのnewを使えばいいじゃない

ただ、例外を使わないようにするとどうせNULLチェックをサボる奴が出てくるので
むしろ有害だと思うけどな

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

155:デフォルトの名無しさん
08/10/23 08:09:11
CAutoPtr

156:デフォルトの名無しさん
08/10/23 11:08:44
>>154
まだ過去の話してんのか
std::tr1::smart_ptrは今では当然のように使う

157:デフォルトの名無しさん
08/10/23 11:46:55
std::tr1::shared_ptrかboost::smart_ptrのどっちかと間違えてるんだと思うが
どっちにしろどうしても必要な所で最低限の使用にしないと重すぎて酷いことになるからなぁ
auto_ptrはそこそこ軽いから割と気軽に使える

まあ、本当は生ポインタが一番いいんだけどな
プログラマが楽をするためだけにスマポの莫大なオーバーヘッドを持ち込むのは感心できない

158:デフォルトの名無しさん
08/10/23 12:17:44
プログラマに苦労を強いると、バグの発生率が跳ね上がるでしょ。
多くの状況ではオーバーヘッドよりバグの方が深刻な問題になるんだから、楽はすべきだと思うけど。

159:デフォルトの名無しさん
08/10/23 13:12:15
C + Boehm GCでいいやん
スマポなんかより便利だし

160:デフォルトの名無しさん
08/10/23 13:21:50
>>157
boost::smart_ptr なんて存在しない。
どっちも shared_ptr。

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

161:デフォルトの名無しさん
08/10/23 19:05:25
boost::intrusive_ptr 方式のスマートポインタが好き。

162:デフォルトの名無しさん
08/10/23 20:50:24
UN*X では Objective-C が使えるから無理して C++ を使う必要は無いよね

163:デフォルトの名無しさん
08/10/23 21:02:12
>>162
極一部のUnix以外ではCが主流というオチ。

164:デフォルトの名無しさん
08/10/23 21:22:07
unixだとc++なんか有象無象とひとつ

165:デフォルトの名無しさん
08/10/23 21:28:01
>>154
ようやく次のC++0xで、コンテナに入れられるunique_ptrが入る。
参照カウントせずauto_ptrと全く同じオーバーヘッド。
まったくもって導入が遅すぎる。

166:デフォルトの名無しさん
08/10/27 19:09:41
C++
↓
C++0x
↓
C++(笑)

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

168:デフォルトの名無しさん
08/10/29 13:34:53
>>167
言いたい事は分かるけど、コピーコンストラクター位はつけた方がいいと思うんだ

169:デフォルトの名無しさん
08/10/29 13:46:13
「解決できるけどデフォルトで放置されている問題」が多いんだな

170:デフォルトの名無しさん
08/10/29 13:55:15
>>167
なんだそれ

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

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

171:デフォルトの名無しさん
08/10/29 14:02:26
STLとかはAllocator差し替えられるけど
alloc()が例外投げること前提に作られてて
NULLチェックなんてしてるわけねーし

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

172:デフォルトの名無しさん
08/10/29 14:03:41
>>170
何言ってるんだ?
君のコンパイラは、

char str1[strlen(hoge) + 1];

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

173:デフォルトの名無しさん
08/10/29 14:05:16
>>172
ああ、いいたいことは分かった
alloca()っぽいことが出来るんだね

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

174:デフォルトの名無しさん
08/10/29 14:09:13
コンストラクタやデストラクタが動くんだからalloca()の代用は言いすぎか

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

175:デフォルトの名無しさん
08/10/29 14:41:56
>>174
newが使われる際の問題って他にあるの?

176:デフォルトの名無しさん
08/10/29 16:21:08
>>167
そんなことするならset_new_handlerとvector（もしくはboost::scoped_array）で十分だと思う。

177:デフォルトの名無しさん
08/10/29 16:50:22
>>176
newが例外をスローしないようにするのなら
vectorなんて使えないんじゃないのか

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

178:デフォルトの名無しさん
08/10/29 17:37:38
>>177
>　new_handlerの中でabort()でも呼ぶのなら
そういう仮定。だって>>167ではexitだったからこそ。

179:デフォルトの名無しさん
08/10/29 18:06:25
そういうことか。よく見てなかった。
つうかabort()だのexit()だの呼んでる時点でダメだろ

180:デフォルトの名無しさん
08/10/29 19:09:35
俺の探し方が悪いのか、abort()だのexit()だの呼んでる以外のサンプルコードを見た事がない

181:デフォルトの名無しさん
08/10/29 19:13:25
ま、new handlerでできることはそれぐらいだろ
つまり、new handlerは、「それでいい」プログラムにしか使えないってことだよ

182:デフォルトの名無しさん
08/10/29 19:39:56
予めでっかいメモリを確保→newハンドラで解放すれば、
ヒープに空きができてnewを成功させられるぜっていう話を聞いたことがある。
実用性皆無にしか思えない。

183:デフォルトの名無しさん
08/10/30 01:39:17
new handler で必ずしも必要でないキャッシュをパージすることが考えられる。
Java の SoftReference がそんな感じ。

184:デフォルトの名無しさん
08/10/30 09:41:16
bad_allocが発生する様な環境下で、必要のないキャッシュを持つ設計が正しいのだろうか?

185:デフォルトの名無しさん
08/10/30 10:01:22
あっちと内容がかぶってる
C++が糞言語なのはみんな知ってるから一箇所でやってくれないかな

186:デフォルトの名無しさん
08/10/30 13:05:43
どこ？

187:デフォルトの名無しさん
08/11/02 04:11:41
>>172
C++ってそんな事も出来ないのかｗ

188:デフォルトの名無しさん
08/11/02 07:33:07
配列ごときをいちいち動的にヒープに取るような非効率言語とは違うんですっ！

189:デフォルトの名無しさん
08/11/02 08:49:23
>>187
Cにも出来ないけどな

190:デフォルトの名無しさん
08/11/02 11:53:20
>>189
Cは低級言語だから別にいいんだよｗ

191:デフォルトの名無しさん
08/11/02 12:23:05
>>190
'C++'の'C'部分に独自の拡張を加えちゃ駄目じゃん

192:デフォルトの名無しさん
08/11/02 12:37:38
C言語は高級言語だろ・・・
抽象化水準が低いから中級言語って言う奴はいたけど。

193:デフォルトの名無しさん
08/11/02 12:54:55
>>189
C99なら嘆かわしいことに出来てしまう

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

194:デフォルトの名無しさん
08/11/03 19:11:25
演算子のオーバーロードはヤバイと
ム半年目の頃に既に俺は思ってたね
関数の引数が参照渡しなのもヤバイ

195:デフォルトの名無しさん
08/11/03 21:30:24
演算子多重定義関数での引数と言えば、const参照が相場だろ。
2行目が値渡しでないからやばいと言っているのであればそれは違う。

196:デフォルトの名無しさん
08/11/03 22:35:07
const参照渡しが安全だと思ってるアホ発見

197:デフォルトの名無しさん
08/11/04 00:23:34
Cに++した程度の言語だ
やばくて当たり前だっての

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

198:デフォルトの名無しさん
08/11/04 00:39:19
本当に C に ++ してくれたのなら、どんなに良かった事か…
本当の意味で C with Class だったら更に良かったんだがな

残念言語

199:デフォルトの名無しさん
08/11/04 02:52:09
>>192
お前その発言がどんだけ化石か自覚してるのか？

200:デフォルトの名無しさん
08/11/04 09:33:16
C++の++は良く分からん物でオーバーロードされてるだろ

201:デフォルトの名無しさん
08/11/05 18:03:54
もしかしたら実際の処理は--かもしれない

202:デフォルトの名無しさん
08/11/05 18:33:56
そしてC++の仕様上、それを知る事は不可能に近い

203:デフォルトの名無しさん
08/11/06 16:48:48
>194-196のやりとりがよくわかりません。
演算子定義をconst参照で受けて、さらに注意しなければいけないことって何？

204:デフォルトの名無しさん
08/11/06 18:08:29
多分、>>196　にしか解らない深い理由があるんだろう。

205:デフォルトの名無しさん
08/11/06 19:33:21
const_cast

206:デフォルトの名無しさん
08/11/06 20:24:16
それくらいでびくついているようではC++なんて使えないけどな。
全くもってそこらじゅう罠だらけだもん。

207:デフォルトの名無しさん
08/11/06 21:22:36
・constなんてconst_castや普通のキャストで誰でも簡単に外せる
・constを外さなくたってmutableメンバがあれば変更し放題
・deleteに対してconstは全く無力

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

208:デフォルトの名無しさん
08/11/06 21:45:34
const_cast は使うこと自体が有害だと思われ

209:デフォルトの名無しさん
08/11/06 21:46:39
気休めにしかならないと分かっていても、すがりたくなる。
ほかに信じられるものなんて何もないから。

210:デフォルトの名無しさん
08/11/06 21:51:57
setの要素を変更する時にconst_castは不可欠です

211:デフォルトの名無しさん
08/11/06 21:58:17
あれってconst付いていたっけ？

212:デフォルトの名無しさん
08/11/06 22:04:48
setの要素を直接変更したらまともに動作しないぞ
removeしてからinsertしないと

213:デフォルトの名無しさん
08/11/07 02:46:00
EffectiveSTLの22番だな

214:デフォルトの名無しさん
08/11/07 03:43:36
比較関数が見ないメンバであれば問題ない。

215:デフォルトの名無しさん
08/11/07 09:35:55
const_castなんてC++の問題ではなく、C++を利用するプログラマの問題だろ

216:204
08/11/07 12:14:46
>>207
やっぱりそういう話か。下らん。

217:デフォルトの名無しさん
08/11/07 16:23:46
で、外注先のプログラマに問題が無い事は誰が保障してくれるんだ？
言語側で保障してりゃ良いだけの事を、本当に非効率的な言語(笑)だわ。

218:デフォルトの名無しさん
08/11/07 17:01:39
問題のあるプログラマを雇っている外注なんぞ切ってしまえ

219:デフォルトの名無しさん
08/11/07 17:05:50
また始まった
ぼくはそんなつかいかたしないからC++はわるくないんだい！！

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

220:デフォルトの名無しさん
08/11/07 17:29:08
何のためにconst_castがあるのかも考えず、不用意に使うような奴を擁護する事の方が信じられん
きっと、大阪の轢き逃げみたいな事件を起こすような奴に違いない

221:デフォルトの名無しさん
08/11/07 17:53:25
はいはい、今度は論点のすり替えですね
フルコースですか
次のメニューをお願いします

222:デフォルトの名無しさん
08/11/07 17:54:41
レッテル張りも消化済みでしたね
引き続きどうぞ

223:デフォルトの名無しさん
08/11/07 18:12:17
そもそも、言語側で保障する方が非効率だから、保障しなかったのにね

224:デフォルトの名無しさん
08/11/07 20:36:53
const_castはどう考えても内容を変更しないのになぜか非定数を要求するAPIのためのもの。

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

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

226:デフォルトの名無しさん
08/11/07 23:36:09
アホな事する奴がconst_castなんて律儀に書くわけないという

227:デフォルトの名無しさん
08/11/07 23:42:36
そういうアホは自分に影響が無い程度に放っておけばいいんです。

228:デフォルトの名無しさん
08/11/08 18:01:46
どうしてSTLってstd::の中に全部ぶち込んでるの？
整理とか出来ない人が作ったの？

229:デフォルトの名無しさん
08/11/08 18:40:10
とりあえず、グローバルに全部散らばっているよりは遥かにましです。

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

231:デフォルトの名無しさん
08/11/08 22:32:08
>>228
あなたならどう整理する？

232:デフォルトの名無しさん
08/11/08 23:17:56
.NETみたいに

233:デフォルトの名無しさん
08/11/09 02:10:38
名前空間も罠の塊だからあんまり多いと困る

234:デフォルトの名無しさん
08/11/09 16:31:19
>>233
using namespaceとか使うから罠に嵌るんじゃないのか?

235:デフォルトの名無しさん
08/11/09 17:00:09
そんなもん使わなくったって落とし穴はいくらでもあるよ
C++にはKoenig Lookupという素敵な仕組みがあるから

236:デフォルトの名無しさん
08/11/10 08:50:37
signed　と　unsigned　の比較くらいできるようにしてくれっつーの！
ヽ(｀Д´)ﾉ

237:デフォルトの名無しさん
08/11/10 12:49:34
signed廃止しようぜ
負の数なんてなくても平気

238:デフォルトの名無しさん
08/11/10 14:23:58
>>226
そういう奴はふつー、Cスタイルのキャスト　(万能)　使うよなあ。

239:デフォルトの名無しさん
08/11/10 23:39:57
>>237
そしてsigned_intクラスを作るんでしょ。

240:デフォルトの名無しさん
08/11/11 03:31:15
暗黙の変換がなくなるだけでも上等。

241:デフォルトの名無しさん
08/11/11 10:36:41
分の悪い取引だな