13/03/20 21:47:42.33
>>501
throw するときに必ず if を使うと思うが？
512:デフォルトの名無しさん
13/03/20 21:48:28.56
異常時に例外を使う話だと思ってるアホは>>459から読み直せよ
513:デフォルトの名無しさん
13/03/20 21:49:05.43
>>489
catch漏れによる異常終了とか、逆に全部補足によるエラーの握りつぶし
前者は例外を追加したときに起こりやすいけど、そうでなくても標準以外の例外まで把握しないとならないとか仕事じゃ使い物にならないし、後者は障害発生の兆しを見逃すことになるから問題外。
標準で発生する例外を捕捉するのは当たり前なのだけどthrowで標準以外の例外まで投げられたらたまらないだろう。常にそれを全部把握していないといないんだよ？
だから使わせない。
javaのせいで同一視されがちだけど例外とエラーの違いはOS関係のエラーとアプリケーションによるエラーという認識なんだ。
514:デフォルトの名無しさん
13/03/20 21:50:43.71
>>512
もちつけ
誰と戦ってるんだ？
515:デフォルトの名無しさん
13/03/20 21:50:46.48
>>477
申し訳ないが、実装が使用法を規定する、とはどうしても考えにくいのだが。
516:デフォルトの名無しさん
13/03/20 21:51:52.88
>>511
重要なポイントは伝播に有る
例外の伝播はなんの苦労もないが
エラーコードチェックは何層にも渡りイフを繰り返さなければならない
これは無論正常系でも同じことでこのオーバヘッドがプログラム全域で積み上がるとバカに出来ない無駄となるわけだ
517: ◆QZaw55cn4c
13/03/20 21:52:32.30
>>491
例外の実装が SjLj ならレジスタを総入れ替えするだけだからきわめて高速。
実装が使用法を規定するなんて考えられない。
518:デフォルトの名無しさん
13/03/20 21:54:09.94
>>513
素人かよ
標準例外だけなんてバカなこと言ってるから例外を使いこなせない
519:デフォルトの名無しさん
13/03/20 21:59:31.78
>>516
で、throw を使えば、ifはいらないの？
520:デフォルトの名無しさん
13/03/20 22:00:50.28
>>516
なんでお前catchするときの話してんの？
521:デフォルトの名無しさん
13/03/20 22:06:46.24
>>513
対処漏れの可能性については、エラーが無視されるほかの通知方法よりちゃんと異常終了する例外のがマシだろ。
エラーの握りつぶしの可能性だって、例外なら明示的にやることになるから起こりづらいし見つけやすい。
例外を全部把握していないといけない、などということもない。興味の無い例外は上部のハンドラに引っかかれば
十分なことがほとんど。
例外とエラーの違いについてのその認識も、何の役に立つのかわからない。
522:デフォルトの名無しさん
13/03/20 22:07:51.22
>>519
いらないよ
523:デフォルトの名無しさん
13/03/20 22:08:30.98
>>520
しない時の話なんだが？
524:デフォルトの名無しさん
13/03/20 22:10:09.94
>>515
そんな話はしてないから安心していいよ。
525:デフォルトの名無しさん
13/03/20 22:12:33.84
安心できないねえ
526:デフォルトの名無しさん
13/03/20 22:13:00.16
>>522
なんで？
throw する条件を満たしているかどうかのチェックはどうするの？
527:デフォルトの名無しさん
13/03/20 22:14:03.03
>>477 のどこをどう読んだら「実装が使用法を規定する」なんて話だと思うのかな。
528:デフォルトの名無しさん
13/03/20 22:14:36.41
エラーは例外の一種に過ぎないのに
エラー以外は例外にしてはいけないと凝り固まっている奴がいるんだな
529:デフォルトの名無しさん
13/03/20 22:15:29.44
>>526
バカやなー
流れ追いきれてないよ
530:デフォルトの名無しさん
13/03/20 22:22:02.69
そのifなしでthrowする具体的なコードを見たいんだけど
531:デフォルトの名無しさん
13/03/20 22:23:27.02
それがエラーなのかという問題と
それは例外的状況かという問題と
それに例外機構を使うかという問題は
それぞれ独立していて、都度都度判断すべきだろ
532:デフォルトの名無しさん
13/03/20 22:24:29.42
>>530
アホ
そんな話してない
533:デフォルトの名無しさん
13/03/20 22:27:42.77
お前らの書いたソースコードって可読性低そうだよね
534:デフォルトの名無しさん
13/03/20 22:31:16.01
何か、間違った再帰の使い方をしている人が、持論を展開してないか？
そもそも、エラーや例外の入るような処理に再帰は適さないと思うのだが。
通常の再帰は戻り値のチェックは行わないで、return で繋いで行くものなので、再帰末尾にreturn を使おうが throw を使おうが余り関係ない。
ほんのちょびっとthrow の方が遅いくらい。
535:デフォルトの名無しさん
13/03/20 22:31:40.81
>>507
> 例外やエラー時に、exception を使う事自体には何の問題もないと思うが、そこに速度の話を持ち込むのはいかがなものかと思うぞ。
エラー時や例外時にexception使うのは問題ないのは間違いない。
ここでの話題はエラー時ではない方の例外時に当てはまるかをどう判断するかだろう。
> 正常系の終了処理とかでexception を使うとか言うのは、会社ではやめた方がいいと思う。
正常系の中のエラー以外の例外時にexception使うのは何の問題もないと思ってるんじゃないのか？
536:デフォルトの名無しさん
13/03/20 22:41:41.12
>>517
速いのはDW2じゃなかった？
537:デフォルトの名無しさん
13/03/20 22:43:28.57
>>536 それはたぶん throw しないときのオーバーヘッドの話。
538:デフォルトの名無しさん
13/03/22 06:19:18.86
ついにC++がゲーム開発にも使われなくなりそうだけど気分はいかが？
539:デフォルトの名無しさん
13/03/22 06:27:45.34
>>538
どこの会社で？
540:デフォルトの名無しさん
13/03/22 07:16:09.02
ゲームほどパフォを追及する分野でC++を使わないとか考えられないのだが‥‥
いったいかわりにどんな言語を使うのか？
541:デフォルトの名無しさん
13/03/22 07:19:14.79
jsとか言い出すに５００円
542:デフォルトの名無しさん
13/03/22 07:20:36.28
時代は変わったってこった。
＞いったいかわりにどんな言語を使うのか？
そういうのもういいから。何の言語があがろうが打ち負かしたくなるのが君のような人でここの住人だろ。そういう流れにするな
543:デフォルトの名無しさん
13/03/22 07:57:15.11
今やゲームはミドルウェアで開発するのが主流だからな
そこではC++ではなく、より素早く開発できる言語が用いられる
我々はもうOSを開発するしかないんだ
544:デフォルトの名無しさん
13/03/22 07:59:48.65
＞(俺の知ってる範囲では)ついにC++がゲーム開発にも使われなくなりそうだ(と耳にした)
545:デフォルトの名無しさん
13/03/22 08:24:46.26
＞(俺の知ってる範囲では)ついにC++がゲーム開発にも使われなくなりそうだ(という事にしないと俺の気が済まない)
546:デフォルトの名無しさん
13/03/22 08:45:15.12
マジでハイスペな超美麗ゲームでもなきゃ今時のマシンでCPPはオーバーすぎるよ
547:デフォルトの名無しさん
13/03/22 09:01:51.20
＞超美麗ゲーム
あぁ昨今の画だけの内容無いゲームのアレね。
548:デフォルトの名無しさん
13/03/22 09:11:02.48
c++だと中身のこと考えてる余裕ないからな
549:デフォルトの名無しさん
13/03/22 09:32:58.68
画面叩くだけでカードをゲットするようなゲームならC++は要らないな
まあ、ミドル以下は必須だろうけど
550:デフォルトの名無しさん
13/03/22 10:17:12.10
だけど市場はそれを必要としていないというか、
＞画面叩くだけでカードをゲットするようなゲーム
を大手は本腰入れてやってるんだよね
551:デフォルトの名無しさん
13/03/22 10:41:43.73
まだC++にスクリプトを組み合わせるのが主流だよ
スマホ向けとか一部unityを使った開発とかはC++使わないけどまだ少数派だね
大手も力入れてるけど、開発じゃなくて広告の方に金を投入してるだろ
552:デフォルトの名無しさん
13/03/22 10:57:55.60
なんでスクリプトなんかつかうんだろ
553:デフォルトの名無しさん
13/03/22 10:59:45.93
プログラマがイベント直打ちしてたら高くつくから
554:デフォルトの名無しさん
13/03/22 11:04:49.71
なんか組み込みスクリプトで開発効率あげたぜぇ～っていうとかっこいいじゃろ
555:デフォルトの名無しさん
13/03/22 11:10:22.44
技術的にはスクリプトもC++もそんなに変わらんと思うが。
556:デフォルトの名無しさん
13/03/22 11:12:45.52
テストが楽だからな
無駄なコンパイルは馬鹿のすること
557:デフォルトの名無しさん
13/03/22 11:14:58.62
スクリプトってjavascriptとか？
それとも独自スクリプトを作って
ゲームプログラム本体がゲーム機のCPU使って実行するの？
そんな仕組みにしてまでスクリプト使うんだね。
558:デフォルトの名無しさん
13/03/22 11:17:46.88
スクリプトで世界が周りだしてるのに何をいってるんだ
559:デフォルトの名無しさん
13/03/22 11:18:14.71
今だにスクリプト否定派居るんだな
逆に実行速度が足りてる部分にC++使う理由がないんだが？
560:デフォルトの名無しさん
13/03/22 12:23:16.59
老害ここに極まれりだな
スクリプトと聞いてjavascriptとか
561:デフォルトの名無しさん
13/03/22 13:06:39.97
こんな実のない議論して。みんな暇なんだな。
562:デフォルトの名無しさん
13/03/22 15:02:09.87
2ch書き込んでる奴で暇じゃない奴なんていねーよ
563:デフォルトの名無しさん
13/03/22 17:20:38.47
JISC のサイトで見れる C++ の規格って索引が無いっぽいんだけど、みんなどうしてんの
564:デフォルトの名無しさん
13/03/22 17:38:56.94
>>563
買えって事だよ
あれはスキャン、しかもわざと荒くスキャンしただけ
565:デフォルトの名無しさん
13/03/22 17:45:51.46
自分で作ってますよ
自動で
566:デフォルトの名無しさん
13/03/22 18:01:45.92
ISOの方しか読んでない
567:デフォルトの名無しさん
13/03/22 20:07:50.12
で、何スクリプトを使うんだ？
568:デフォルトの名無しさん
13/03/22 20:16:29.86
IT業界はちゃんとしたプログラマーに金を出さないから
世の中糞みたいなソフトだらけになるんだよな。
まずC++もできないような頭の奴に仕事を出すのが間違いなのでは？
569:デフォルトの名無しさん
13/03/22 20:53:06.81
LuaとかC++に組み込んで使ってる
570:デフォルトの名無しさん
13/03/22 21:01:34.95
>>568
今だにC++に幻想抱いてるコンクリート脳に仕事出す方が危険だよ
571:デフォルトの名無しさん
13/03/22 21:30:27.80
C++まともに使える奴探すと人が集まらないんだよ
572:デフォルトの名無しさん
13/03/22 23:47:11.58
ガベコレのある言語って、ゲームにどこまで使えるの
573:デフォルトの名無しさん
13/03/22 23:51:34.64
>>571
金のなる木である大規模プロジェクトに使えないようじゃだめだからな
574:デフォルトの名無しさん
13/03/22 23:52:23.78
馬鹿
575:デフォルトの名無しさん
13/03/23 02:11:37.85
>>573
さすがに、そんな事は無いだろ。gnue compilerもたしかC++に移行だし、
他にも、近頃はC++派が多い。特にgoogle周りには。
単純に日本だとC++が出来ても評価できる上が居ないから、
人材が流出しやすいだけだと思うよ。
まぁ、なんというか日本の環境が～とか言う気は無いけど、
勉強しつづけられる人じゃないとC++はね・・・
576:デフォルトの名無しさん
13/03/23 02:15:20.86
C++98 C++03 C++11 C++14 C++17 ...
577:デフォルトの名無しさん
13/03/23 03:23:12.01
最強は
CC++999
578:デフォルトの名無しさん
13/03/23 07:00:19.62
>>576
そんな高レベルな話じゃないっしょ
日本でC++プログラマ集めるとメモリリークとかアクセスバイオレーションとか
起こしてそれで何日もはまるようなPGばっかで・・とかそのレベルっしょ。
579:デフォルトの名無しさん
13/03/23 09:27:51.29
素人の俺でもアプリ作るのにメモリリークなんか一度もした事無いのにメモリリークさせる職業プログラマなんて本当に実在するのか？架空の人物像で騙そうとしてないか？
580:デフォルトの名無しさん
13/03/23 09:35:20.47
関係ないけど想像力が足りない人って怖いよね。関係ないけど
581:デフォルトの名無しさん
13/03/23 09:47:25.09
>>579
世の中にはアプリと呼べるような規模や複雑度では解決できない問題が山積してるのぢゃ
582:デフォルトの名無しさん
13/03/23 09:48:31.08
むしろ一人の方がメモリリーク発生しにくいんじゃないの
583:デフォルトの名無しさん
13/03/23 10:05:29.62
まぁ今は広く普及したスマポがあるしな
スタックぶっ壊す奴はいまだにいるけど
584:デフォルトの名無しさん
13/03/23 10:18:25.13
広く…
585:デフォルトの名無しさん
13/03/23 10:20:00.64
スタンダードやん
586:デフォルトの名無しさん
13/03/23 11:11:13.95
>>579
居るからJavaやVBが選択されたんだろ。
587:デフォルトの名無しさん
13/03/23 11:13:40.48
でもそれって正規のプログラマじゃなくて派遣奴隷とか野良PGでしょ？
それならプログラマって呼ばないでほしい
588:デフォルトの名無しさん
13/03/23 11:22:22.34
儲からなきゃ何をほえても無駄。君が言うプログラマと呼べないやつでも商いを成功させていたら評価できるんだよ。
君より知識のない若手でもその辺しっかりしてるヤツは多い。
589:デフォルトの名無しさん
13/03/23 11:28:01.87
マ板でやれ
590:デフォルトの名無しさん
13/03/23 11:29:10.31
誰も金の話なんてしてないのに詭弁のテンプレですな
591:デフォルトの名無しさん
13/03/23 11:30:54.74
あほやなぁ
儲けたいならPGになんかならねぇよ
その時点で負けなんだからあとはカスどうしで腕のよしあし競うしかないだろ
592:デフォルトの名無しさん
13/03/23 11:31:17.32
社会の話してるだろ
それとも日本社会は金でまわっていないと妄信してる学生か？
593:デフォルトの名無しさん
13/03/23 11:32:47.03
>>592
今度は拡大解釈ですかｗ
594:デフォルトの名無しさん
13/03/23 11:36:00.74
哀れな奴隷たちが必死に自分たちは金を社会を動かしてるんだとわめいている
金や社会を動かしてるのは別のやつでお前らは機械的に与えられた処理をしてるだけなんだよ
電気を与えられたコンピューターのように、はした金をエネルギーに変えて計算する機械
それがPGだ。一著前になにかを成し遂げたような気になっているんじゃあないぞッ！！
595:デフォルトの名無しさん
13/03/23 11:43:04.46
暇人品評会会場
596:デフォルトの名無しさん
13/03/23 12:46:56.81
>>588
そいつらは別に商いを成功させてるんじゃなくて
そいつらをこき使って商いしてるやつが成功してるだけで
本人たちは糞みたいな時給です。
つまりちゃんとした技術者がちゃんとした給料を受け取れないのは
業界の違法なサービス残業や偽装請負などで薄利多売で無茶するから。
そしてそれはソフトウエアの品質も下げている。
客は金を払っているが天下りSIerやピンハネ人繰り屋それを盗んでいるので
PGの地位も賃金もソフトの品質も低く、客は高い金を払わざるを得ない。
597:デフォルトの名無しさん
13/03/23 13:01:37.74
で、言語仕様と何か関係でも？
598:デフォルトの名無しさん
13/03/23 13:08:43.57
ぐうの音も出ないようです
599:デフォルトの名無しさん
13/03/23 13:41:58.01
C＋＋のpathの変数値を間違えて消してしまったんですが、どこで変数値は分かりますか？
600:デフォルトの名無しさん
13/03/23 14:11:55.42
諦めて再インストールしろ
601:デフォルトの名無しさん
13/03/23 14:57:23.10
Javaや.NET CLRでもリークさせることは可能。
リストに際限なく要素を突っ込んでいけばいずれ限界がくる。
リークのしやすさに違いはあるが、最終的には設計のわかりやすさと
担当レベルの技術力しかない。
602:デフォルトの名無しさん
13/03/23 15:13:08.59
>>601
それリークじゃないじゃん
単にメモリを使い果たしただけ
603:デフォルトの名無しさん
13/03/23 15:37:43.49
そもそも「メモリリーク」ってどんな現象なんだ？
使い終わったメモリ領域を再利用しないでいるのがメモリリークとちゃうの？
604:デフォルトの名無しさん
13/03/23 15:49:16.00
リソースを制御する情報が失われ
リソースを解放できない状態
605:デフォルトの名無しさん
13/03/23 15:53:05.22
ということは、解放し忘れとリークは全くの別物か
解放し忘れ ： 解放しようと思えばいつでも解放できる
リーク ： 解放不可能
606:デフォルトの名無しさん
13/03/23 15:57:33.75
ん？ じゃあ、厳密にはメモリリークは検出できない？
607:デフォルトの名無しさん
13/03/23 16:03:42.76
使用メモリが増えてけば
たいていはメモリリーク。
確保と解放の時にアドレスをログに
出しておけば
漏れたかどうかはわかる。
608:デフォルトの名無しさん
13/03/23 16:03:56.48
>>603
C/C++でダングリングポインタと呼ばれる現象がそれ
つまりmalloc/newで確保した領域を解放する手段がなくなる
GCを備えている言語では原理的にメモリリークは発生しない
単なる怠慢
609:デフォルトの名無しさん
13/03/23 16:06:43.91
>>607
それは、リークなのか解放し忘れなのか検出できんことない？
610:デフォルトの名無しさん
13/03/23 16:06:52.89
>単なる怠慢
主語は何かな？
611:デフォルトの名無しさん
13/03/23 16:07:11.57
メモリリークについて正しい意味を知りたかったらExceptional C++の第2章を熟読しろ
ただしGC言語でもリソースリークはあり得る
例外が発生したらリソースを解放するパスが二度と実行されない可能性はある
612:デフォルトの名無しさん
13/03/23 16:12:35.43
>>610
お前難癖付けて理解したくないだけだろうがカス
重箱の隅をつつくようなマネをする前に意味が分かるだろうが
613:デフォルトの名無しさん
13/03/23 16:13:19.88
答えたくないなら答えなくてもいいですよ、もちろん。
614:デフォルトの名無しさん
13/03/23 16:49:37.90
>>606
エレクトリックフェンスとか使えばできんじゃね？ 使ったことないけど
615:デフォルトの名無しさん
13/03/23 20:32:01.91
>>608
＞>>603
＞C/C++でダングリングポインタと呼ばれる現象がそれ
ちげーよ。10年ROMってろ、ヘボ
616:デフォルトの名無しさん
13/03/23 20:33:55.80
なんでリーク起こるの？スマートポインタ使ってもダメなの？
617:デフォルトの名無しさん
13/03/23 20:37:02.33
意外ッ！！それは循環参照ッ！！！
618:デフォルトの名無しさん
13/03/23 20:48:48.85
ダングリングポインタっつうのはダングリング状態のポインタのことだよ
619:デフォルトの名無しさん
13/03/23 20:49:49.88
例外安全という概念があってのう
620:デフォルトの名無しさん
13/03/23 20:55:09.65
>>615
メモリの枯渇とメモリリークをごちゃ混ぜにすんな
621:デフォルトの名無しさん
13/03/23 20:55:58.77
例外処理中の例外て考慮しますか？
622:デフォルトの名無しさん
13/03/23 21:00:27.35
>>620
寝ぼけたふりしてとぼけてんじゃねーぞ
ダングリングポインタを説明してみろ
623:デフォルトの名無しさん
13/03/23 21:00:35.72
例外処理中の例外は即terminate()される
624:デフォルトの名無しさん
13/03/23 21:06:47.38
連レス失礼
terminateはデストラクタでの例外だった、catch節中の例外はより外側のtry-catch節で捕捉されるはず
625:デフォルトの名無しさん
13/03/23 21:15:04.69
メモリーリークというのはアプリケーションの処理のサイクルのなかで
本来解放すべきメモリーを開放せず、サイクルが進むにしたがってメモリが無駄に枯渇する現象で設計ミスです。
C#などでは参照を管理しているので、参照がなくなれば消してもらえるが
参照しっぱなしなら結局リークしていることになる。
ただしC#では参照しっぱなしという状態は作りにくい。
リストにガンガン突っ込み続けるとかそういう本当にアホな事をしないと起きない。
626:デフォルトの名無しさん
13/03/23 21:17:02.14
GCってVRAM回りにも効くの？
627:デフォルトの名無しさん
13/03/23 21:37:14.05
void X::Func() {
try {
// DoSomething
} catch(exception const & e) {
string s("ERR in X::Func(void);");
s += e.what();
throw X::Exception(s);
}
こんな感じで例外にデバッグ情報を追加していってるんだけどstringでbad_allocしたらどうするべきなんだろう
628:デフォルトの名無しさん
13/03/23 21:46:08.03
bad_allocしないallocator
629:デフォルトの名無しさん
13/03/23 21:48:38.91
素直に終わっといたほうがよくね
630:デフォルトの名無しさん
13/03/23 22:04:29.45
>>627
再throwで型を変えてしまったら「デバッグ情報を追加していってる」にはならないよな？
631:デフォルトの名無しさん
13/03/23 22:06:15.33
try {
func();
catch(MyException&e) {
e.add_debug_info(foo);
throw;
}
632:デフォルトの名無しさん
13/03/23 22:07:20.45
うーんならどうするのがいいのだろう
深いところで例外を投げられてそれが伝播してくともうどこで起こったかぜんぜんわからないんですよね
633:デフォルトの名無しさん
13/03/23 22:13:27.42
>>632 Boost.Exception を使え。
634:デフォルトの名無しさん
13/03/23 22:29:19.99
>>625
だからその参照を管理しているのを消せば勝手にGCが走った時に解放されるでしょ？
ダングリングポインタというのは例えば
int* a = new int; // (1)
a = new int; // (2)
とやった時に(1)でnewした部分を解放する手段がなくなる事を言う
こういうのが本当のメモリリーク
GCを備えている言語ではメモリの枯渇は起きてもメモリリークはおきない
ちゃんと自分で参照を消せばそれでいい話
635:デフォルトの名無しさん
13/03/23 22:33:22.05
だから
じゃねえんだよ
そんなもんわかってんだよ
広義では参照解放しないのもメモリーリークだっつってんだろ
市ね
636:デフォルトの名無しさん
13/03/23 22:34:54.11
ダングリングポインタでググろう！な！
637:デフォルトの名無しさん
13/03/23 22:35:36.59
>>635
参照を解放しないのは単なる手落ちだろ
相変わらず参照を解放する手段は残ったままだ
それはメモリリークではない
故意であろうとバグであろうと解放する手段が残っているうちはメモリリークではない
解放する手段がなくなった時がメモリリーク
638:デフォルトの名無しさん
13/03/23 22:36:41.73
>>636
ダングリングポインタについては俺が誤解していた
しかし>>637で言った事は変わらないぞ
639:デフォルトの名無しさん
13/03/23 22:37:10.88
>>634
このバカ、本当にダングリングポインタしらねーでやんの。
晒し上げ
640:デフォルトの名無しさん
13/03/23 22:38:48.19
無理やりダングリングポインタでメモリリークを説明するならば、
int* p = new int; // (1)
p = 0; // (2)
(2)の時点でpはダングリングポインタになる
そして(1)で確保した部分を解放する手段がなくなるので
この時点でメモリリークを起こしたと言える
641:デフォルトの名無しさん
13/03/23 22:38:56.85
>>635
「広義」なんて言葉、このスレで初めてだ
642:デフォルトの名無しさん
13/03/23 22:42:19.34
>>641
ほっときゃいいよ
643:デフォルトの名無しさん
13/03/23 22:42:40.10
>>637
参照を解放する手段がなくなってる時の話をしてるんだが。
たとえば参照を握ってるコンテナからの削除に至るUIが無い場合とかね。
644:デフォルトの名無しさん
13/03/23 22:43:48.11
>>640
このバカ、まだダングリングポインタを理解して無い。
645:デフォルトの名無しさん
13/03/23 22:44:15.13
>>643
具体的なコードで頼む
646:デフォルトの名無しさん
13/03/23 22:48:06.94
>>643
参照を握ってるコンテナがスコープを外れたらGCでコンテナごと削除されるんだけど
647:デフォルトの名無しさん
13/03/23 22:52:39.52
>>645-646
↓これで伝わるかな？
class UI {
private static Container<Object> objects;
public void add(Object x) { objects.add(x); }
public void remove(Object x) { /* コンテナからの削除を書き忘れた */ }
// ...
}
アホなコードだと思うだろうが、こういうアホなことをすればGCのある言語でも
メモリリークという現象は生じることになる。
648:デフォルトの名無しさん
13/03/23 22:52:54.79
もしかしてDとかJavaとかC#を一度も触った事がない奴がファビョってるだけか
649:デフォルトの名無しさん
13/03/23 22:53:38.69
>>647
それ単なるバグ
メモリリークではない
650:デフォルトの名無しさん
13/03/23 22:57:05.67
最近C++
使えてもC#は使えないって話がでてますけど
本当でしょうか？
C++使えれば多言語でもできそうな気がするけど
651:デフォルトの名無しさん
13/03/23 22:57:33.33
>>647
なんか他の部分の実装次第で起こりそうな起こらなさそうな・・・
652:デフォルトの名無しさん
13/03/23 23:00:01.26
>>649
単なるバグだったらメモリリークじゃないって言うの？
単なるバグじゃないメモリリークのほうが少ないと思うんだけど・・・。
お前の中の「メモリリーク」の定義を整理して書き出してくれ。わけがわからない。
653:デフォルトの名無しさん
13/03/23 23:00:08.33
>>647
あーいや、objectの追加削除に関しては他の実装部分がないのか・・・
すると手段がなくなった時点で、という定義に照らし合わせるとメモリリーク？
654:デフォルトの名無しさん
13/03/23 23:00:36.58
メモリリークって Wikipedia で見ると、日本語版と英語版で説明が違くね？
日本語版 :
プログラムが確保したメモリの一部、または全部を解放するのを忘れ、
確保したままになってしまうことを言う。
英語版 :
In object-oriented programming, a memory leak may happen
when an object is stored in memory but cannot be accessed
by the running code.
日本語版は「解放忘れ」、英語版は「アクセスできない」
まぁ、チラッと読んだだけだから、
結局同じ事を違う言葉で言ってるだけなのか知らんが。
655:デフォルトの名無しさん
13/03/23 23:03:36.70
>>653
解放する手段はあるだろ
Containerに直接触ればよい
クラスで包んで「あー解放できないやー」とか言って誤魔化してんじゃねーよ
656:デフォルトの名無しさん
13/03/23 23:04:36.16
>>654
英語版はmay happenなので定義ですらない気がする
>>653
自己レスだが訂正すると、UIにaddされたオブジェクトが他で開放されてれば別にメモリリークじゃなくなるな
657:デフォルトの名無しさん
13/03/23 23:05:43.71
>>655
インスタンスのobjectsにはアクセスできなくね？
658:デフォルトの名無しさん
13/03/23 23:06:40.15
>>655
んなこと言い出したらCのfree()忘れだって「ヒープに直接触ればよい」わけで、メモリリークにならんぞ。
659:デフォルトの名無しさん
13/03/23 23:07:27.28
どうでもいい
けれどきになるお年頃
660:デフォルトの名無しさん
13/03/23 23:07:46.35
>>657
だからインターフェースのバグだっつーの
オブジェクト指向によるprivateと解放する手段がなくなる事を同じ意味で捉えるな
661:デフォルトの名無しさん
13/03/23 23:08:26.09
>>658
話が飛躍しすぎ
外行って頭冷やしてこい
662:デフォルトの名無しさん
13/03/23 23:10:19.25
お前の中の「メモリリーク」の定義を整理して書き出してくれ。わけがわからない。
663:デフォルトの名無しさん
13/03/23 23:10:20.41
>>660
メモリリークの定義が、アクセスする手段がなくなった時点で、ということなんだよね？
privateはその一種なのでは？
664:デフォルトの名無しさん
13/03/23 23:12:06.78
>>663
>>654の英文が果たしてオブジェクト指向を考慮した物かどうか分からなければ
これ以上議論しようがない
665:デフォルトの名無しさん
13/03/23 23:13:56.13
というか>>654は
In object-oriented programming,
で始まってるんだからprivateも含むような気がする
666:デフォルトの名無しさん
13/03/23 23:15:24.33
プロセスを開放すればメモリも開放されるんだから
メモリ解放の手段がないのがメモリリークというならWindows95まで立ち返らないとダメだな。
667:デフォルトの名無しさん
13/03/23 23:16:56.58
>>666
by the running code
668:デフォルトの名無しさん
13/03/23 23:16:59.41
例えばprivateなコンテナをメンバに持つclassをnewして、それをプログラム終了時まで
使うとすれば、もしこのclassにコンテナから削除するコードがなければメモリリークだな
669:デフォルトの名無しさん
13/03/23 23:17:54.05
>>667
俺はWikiの話なんかしてない
670:デフォルトの名無しさん
13/03/23 23:20:52.30
typedef std::shared_ptr<foo> Object;
class UI{
static std::vector<Object> objects;
public:
void add(Object x) { objects.push_back(x); }
void remove(Object x) { /* コンテナからの削除を書き忘れた */ }
};
うーん・・・
671:デフォルトの名無しさん
13/03/23 23:22:41.15
>>670
だからさ、保護レベルもメモリリークの一因だと決着が付いたんだからそれでいいんじゃね
672:デフォルトの名無しさん
13/03/23 23:28:21.61
GCあればメモリリークはおきないとか言ってたバカは居なくなったか。よかったよかった。
673:デフォルトの名無しさん
13/03/23 23:31:52.52
>>672
かんぱーーーーい
674:デフォルトの名無しさん
13/03/23 23:34:05.85
このスレに居なくなったからといって存在しなくなったわけではない
その考えこそメモリーリークみたいなものでは
675:デフォルトの名無しさん
13/03/23 23:35:00.91
shutdown
676:デフォルトの名無しさん
13/03/23 23:35:22.36
うまいこといってしめるな
677:デフォルトの名無しさん
13/03/24 00:35:48.88
「解放し忘れてますがアクセス手段は残ってます。だからメモリリークじゃありません！」
このボケ死ね。
もういいから己を生から解放しろ。
678:デフォルトの名無しさん
13/03/24 00:41:00.12
delete [] me;
679:デフォルトの名無しさん
13/03/24 00:43:54.25
多重人格か
680:デフォルトの名無しさん
13/03/24 02:03:57.27
いいこと思いついた。
1日1回サーバー再起動すれば
メモリリークなんて無くなるんじゃね？
681:デフォルトの名無しさん
13/03/24 02:27:22.43
1日20Mづつリークするけど月１でリブートするから
対応しなくておkってシステムあったわ。ちなみに官公庁
682:デフォルトの名無しさん
13/03/24 02:47:09.30
合理的じゃないか
逆になぜ金をかけて治したがるのか？
683:デフォルトの名無しさん
13/03/24 02:49:56.87
>>681
そりゃ発注側はプログラマーのオナニーの為
じゃなくて、サービスを提供するために
金払ってるからな。
「プログラマーはバグだらけのシステムしか作れないクズ」
と割り切るのには慣れているだろう。
684:デフォルトの名無しさん
13/03/24 02:53:55.60
リブートって了解取るのが結構面倒なんだよ
相手が行政だとなおさら
685:デフォルトの名無しさん
13/03/24 03:11:41.75
1.参照されず(未定義でない環境非依存のコードでは)解放できない状態派
2.参照されてないけど標準ライブラリの内部データをいじって解放できたらリークじゃない派
3.参照されていても解放が実行されないバグ派
4.再起動最強。リークなんて幻想派
昔は1をメモリリークということが多かったけど
3もまあいいんじゃないかと思う。
2と4はこのスレで初めて見た。
686:デフォルトの名無しさん
13/03/24 04:58:31.36
>>685
それだけ自分の意見を通すだけのためにデタラメを言う奴が多いって事だ
687:デフォルトの名無しさん
13/03/24 07:16:09.33
例外処理中の例外について上でちょっと出てたけど、C/C++って上の階層に例外投げられないの？
688:デフォルトの名無しさん
13/03/24 09:09:59.91
できるよ
689:デフォルトの名無しさん
13/03/24 09:30:49.10
↓例外の情報追加はこれがお勧め
template<typename InnerException> class MyException: std::exception {
std::string msg_;
InnerException inner_;
public:
MyException(std::string && s, InnerException && e): msg_(std::move(s)), inner_(std::move(e)) {}
// ry
};
try { do_something(); } catch(std::out_of_range & e) {
throw MyException<std::out_of_range>("error: do something", std::move(e));
} catch(std::bad_alloc & e) {
throw // ry
690:デフォルトの名無しさん
13/03/24 11:44:17.86
>>689
スライスされてんじゃねーか。型も変わってるし、多段にできそうにもないし。
Boost.Exception でいいよ。
691:デフォルトの名無しさん
13/03/24 11:48:59.55
C++の例外むずかしすぎーJavaみたいにして
692:デフォルトの名無しさん
13/03/24 11:49:03.69
どこスラ？
693:デフォルトの名無しさん
13/03/24 11:50:46.43
inner_(std::move(e)) だな
694:デフォルトの名無しさん
13/03/24 11:53:58.01
ちゃんとキャッチすればスライスなんか起こらないだろアホか
695:デフォルトの名無しさん
13/03/24 11:55:54.79
C+11限定じゃねーかという突っ込みはないのか
696:デフォルトの名無しさん
13/03/24 12:07:34.61
というかお前ら例外処理中のメモリ確保はご法度って知らないのか
当たり前のようにstringとかつかってて笑えるんだが？bad_allocで死ぬぞ
697:デフォルトの名無しさん
13/03/24 12:10:20.87
>>696
オリジナルの例外のかわりに bad_alloc が飛ぶだけで、別に死ぬわけではない。
698:デフォルトの名無しさん
13/03/24 12:10:51.45
例外の再スローはメモリ使ってないの？
699:デフォルトの名無しさん
13/03/24 12:20:58.45
>>698
newしてないからつかってないよ
700:デフォルトの名無しさん
13/03/24 12:24:17.69
newしてないから使ってないとは言えない気がするけど（スタックとか
予め確保されてる中でやりくりしてるのかな？
701:デフォルトの名無しさん
13/03/24 12:25:07.20
例外中にログを吐くのもダメですか
702:デフォルトの名無しさん
13/03/24 12:32:15.06
bad_alloc の時は正直余計な処理したら変になりそうで怖いので
死んでくれた方がいい気もする
703:デフォルトの名無しさん
13/03/24 12:37:49.41
>>696
お前は例外ハンドラの中で何をしてるの？
704:デフォルトの名無しさん
13/03/24 12:58:13.42
>>700
スタックが足りなくなったらbad_allocとは違う理由でプロセスが死ぬだろう
705:デフォルトの名無しさん
13/03/24 12:59:09.33
>>701
エラーが出ると危険だ
エラー情報を静的領域に保存してプログラムを安定させてから吐き出そう
706:デフォルトの名無しさん
13/03/24 13:55:23.15
>>705
エラー情報はそれでよくてもI/O処理が内部でメモリ動的に使ってたら意味なくね？
707:デフォルトの名無しさん
13/03/24 14:07:11.60
別プロセスでロガーを立ち上げておいて、
初めからそいつとのパイプを開いておけば良い。
708:デフォルトの名無しさん
13/03/24 14:18:06.71
プロセス間通信エラーったらどうすんの？
709:デフォルトの名無しさん
13/03/24 14:23:27.47
予備のプロセスをあらかじめ立ち上げておいてだな・・・
710:デフォルトの名無しさん
13/03/24 14:30:37.47
予備のプロセスがエラーしたら
711:デフォルトの名無しさん
13/03/24 14:31:32.27
>>705 の言うように予め確保しておいた静的メモリ利領域にログ情報を書き込んで、
最後プロセスが死ぬ時にメモリダンプすればいいじゃん
712:デフォルトの名無しさん
13/03/24 14:31:43.27
例外捕まえてなにするの？
713:デフォルトの名無しさん
13/03/24 14:32:29.25
逮捕しちゃうぞ！
714:デフォルトの名無しさん
13/03/24 14:52:57.58
>>711
ログ書き込む前に死ぬかもしれない
死ぬ前にログを書いた方がマシ
715:デフォルトの名無しさん
13/03/24 15:36:55.43
僕は耳と目を閉じ口をつぐんだ人間になろうと考えた
716:デフォルトの名無しさん
13/03/24 17:37:55.26
友達のあんどろは結構再起動必要みたいだけど
あいほんはOSアップデートの時以外再起動したことないなー
アプリ作ってるときはXCodeで警告だしてくれるけど優秀なのかな
717:デフォルトの名無しさん
13/03/24 23:53:39.43
>>616
いろいろな言い方がされているけれどアプリケーションの実行中にリソースが枯渇する現象を「メモリリークしていた」と説明することもある。
まあ、確保と解放を同じスコープ内で行えるようにしていけば、基本は平気なのだけどね。
でもgcあっても参照されていないことにならなければ解放されないから、gcあるから大丈夫なんてのは都市伝説だと思った方がいい。
メモリリテンションいうのだったかな？
ごめ、用語はわすれた。
718:デフォルトの名無しさん
13/03/24 23:55:43.64
用語もうろ覚えで具体例もなくまさにFUD
719:デフォルトの名無しさん
13/03/25 00:25:38.27
コンサバGCなら解放されない可能性もあるわけだが、これもリークかね?
720:デフォルトの名無しさん
13/03/25 04:34:38.88
>>717
＞確保と解放を同じスコープ内で
なにかの×ゲームですか？
721:デフォルトの名無しさん
13/03/25 05:02:20.10
×ゲームかどうか知りたいならググれ
何でも質問するんじゃない
722:デフォルトの名無しさん
13/03/25 07:23:18.34
スコープを越えて寿命を維持したいからnewをする場面が多かろうに
723:デフォルトの名無しさん
13/03/25 07:24:01.87
まじでC++使われなくなっててワロタ・・・
724:デフォルトの名無しさん
13/03/25 07:34:07.77
普通に仕事で使ってるけど
725:デフォルトの名無しさん
13/03/25 07:35:48.38
C++しかできない俺オワタ
726:デフォルトの名無しさん
13/03/25 08:00:54.99
スコープ超えたいだけならstatic変数でええやん
727:デフォルトの名無しさん
13/03/25 10:21:24.85
std::list::sort以外で
std::listの中身をソートするSTLのアルゴリズムを教えて下さい
728:デフォルトの名無しさん
13/03/25 10:27:21.93
>>727 std::sort