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
分の悪い取引だな