C++相談室 part99at TECH
C++相談室 part99 - 暇つぶし2ch369:デフォルトの名無しさん
13/03/10 00:21:54.37
>>361
だけどやっぱIDEとともに言語って進化するのではなかろうか

370:デフォルトの名無しさん
13/03/10 00:28:52.55
>>369
EclipseとかXcodeなら肯定するけどVSは違うんじゃね

371:デフォルトの名無しさん
13/03/10 00:30:00.38
それならC#もわかりにくいでしょうが

372:デフォルトの名無しさん
13/03/10 00:30:03.51
C#はともかくC++はIDEとは無関係な進化しかしてないな

373:片山博文MZパンク ◆0lBZNi.Q7evd
13/03/10 00:31:05.06
例えばプロジェクトにインクルードパスやライブラリファイルをD&Dで追加できるようにするとか?

374:デフォルトの名無しさん
13/03/10 00:31:57.94
C++はMSの傘下じゃないからな

375:デフォルトの名無しさん
13/03/10 00:32:54.22
いや、D&Dで追加とかじゃなくて、同じ「ライブラリ」を追加するんだから、ライブラリの追加方法は共通であってほしいのだよ
可能な限りね。
言語柄しかたないが、個別に振り分けないといけない設定が多すぎるとは思う

376:デフォルトの名無しさん
13/03/10 00:32:55.86
>>365
>>322
失礼アンカ間違えた

325は取りあえず、cなら論理式かく必要ないしあまり気にならない
強いてするならfalseと比較かな?
0固定で環境依存しないし。

関数の戻りにbool使うのはwindowsの文化だよね
基本はちゃんとエラーコードを返すべき
エラーと真偽値は意味が違うと思うんだ。

377:デフォルトの名無しさん
13/03/10 00:34:30.78
面倒だしコンパイルも遅い
悪い面が多すぎるw

378:デフォルトの名無しさん
13/03/10 00:36:43.18
>>368
おっしゃるとおりですorz
boolつかってないのばればれだ
はずかしー

379:片山博文MZパンク ◆0lBZNi.Q7evd
13/03/10 00:42:33.78
RedHatのRPMっていうのは知ってるよね。あれみたいにライブラリとヘッダーをまとめた共通形式のパッケージを作れば?
インストールされている開発環境を識別する仕組みが必要だな

380:デフォルトの名無しさん
13/03/10 00:53:17.72
プラットフォームに依存した形だと便利になればなるほどIDE等は無秩序になってしまうのがきついな

381:デフォルトの名無しさん
13/03/10 01:03:51.14
MacのFrameworkは比較的簡単に追加できるんだが

382:デフォルトの名無しさん
13/03/10 01:09:43.54
include/
lib/
を開発環境に上書きコピーするだけでライブラリのインストール完了、って形式がいいと思う

383:デフォルトの名無しさん
13/03/10 01:33:08.27
frameworkは楽でよかった
上書き形式だとアンインストールしたいとき少し面倒かもしれない

384:デフォルトの名無しさん
13/03/10 01:38:39.72
>>365,376
流れも読め。>>322はTRUE/FALSEマクロの話からの流れだからC99はお呼びじゃない

385:デフォルトの名無しさん
13/03/10 01:44:57.24
include/*.h
lib/*.lib
bin/*.dll,*.exe
?????_uninstall.bat
コピーしたファイルを消すバッチファイルも付けとくか。

386:デフォルトの名無しさん
13/03/10 01:47:10.72
それ何てconfigure make install
と思ったけどあれは消すとかしてくれなかったか

387:デフォルトの名無しさん
13/03/10 02:02:26.99
確か、make uninstallで消せたはず。

あ゛、UACのせいでバッチが正しく動作しない可能性があった!バッチファイルじゃダメか?

388:デフォルトの名無しさん
13/03/10 02:06:37.03
>>379
色んなスレで初心者に嘘教えて喜んでる精神異常は来るな
スレが荒れるだけ

389:デフォルトの名無しさん
13/03/10 02:09:51.35
>>388 証拠は?

390:デフォルトの名無しさん
13/03/10 02:13:30.99
ファイルの設置自体は何とでもなるけど問題はコンパイルするとき

391:デフォルトの名無しさん
13/03/10 02:21:14.19
>>388
証拠がなければあなたを名誉棄損で訴えますよ。近々東京地裁に出廷してもらいます。

392:デフォルトの名無しさん
13/03/10 02:28:53.70
その人よく知らないけどこういうのはやめたほうがいいと思うな
URLリンク(twitter.com)
URLリンク(twitter.com)

393:デフォルトの名無しさん
13/03/10 02:33:37.41
>>339
そうとも限らないよ
aがbool型でも未初期化ならfalse/trueでもない値になっている可能性がある

394:デフォルトの名無しさん
13/03/10 02:41:30.57
>>391
じゃあ裁判のときに提出するからいいよ
ここだと片山一味が炎上学習法とやらで煽って回答得ようとするからな

395:デフォルトの名無しさん
13/03/10 02:42:24.38
>>393
g++で試した所、== true は最適化されて消されるようだ

396:デフォルトの名無しさん
13/03/10 02:45:18.46
嘘回答とか言うからだろ。

バグ仕込ませる回答、が正解。

397:デフォルトの名無しさん
13/03/10 02:51:32.03
最初実行結果見た時、何が起こったのかしばらく分からなかったわ
URLリンク(ideone.com)

でも流石にbool変数同士を比較する場合にはダメみたいだな
URLリンク(ideone.com)

まあ未初期化な状態で使った時点で鼻から悪魔なんだが

398:デフォルトの名無しさん
13/03/10 02:53:26.69
訴えてもらったほうがいいんじゃね?w
そうすれば片山がどれだけいい加減な知識で
適当なことを言ってるかを公にできるし、
2chで質問したらどれほどの糞情報をつかまされるかを
世の中に知らしめることができるw

399:デフォルトの名無しさん
13/03/10 03:00:49.18
証拠ってこの部分の証拠じゃないの?

>喜んでる精神異常

回答の内容が虚偽であることを証明しろってことじゃなくて、
意図的にそういった書き込みをしていることを証明し、さらに、精神異常と認められるもの(障害者手帳など)をもって証明しろってことじゃないの?
知識が足りないだけで本人は正しいことを書いてると思い込んでるだけならこれは証明できないだろ、ってことじゃないの?

400:デフォルトの名無しさん
13/03/10 03:03:05.86
そろそろ別のところでやってくれない?

401:デフォルトの名無しさん
13/03/10 03:07:41.38
片山の余罪は他にもあるぞ。
質問スレッドの私的利用とかな。
(具体的にはスレッドの趣旨に関係ないブログ的利用など)

402:デフォルトの名無しさん
13/03/10 03:09:59.70
話の流れから雑談に流れたならまだしも何の脈絡もなくこの書き込み↓

スレリンク(tech板:961番)

961:片山博文MZパンク◆0lBZNi.Q7evd :2013/03/10(日) 02:55:15.03 [sage]
あの程度のフリーソフト公開しただけで同業者に恨まれるんだよな。フリーソフト作者は匿名がいいぞまじで。

403:デフォルトの名無しさん
13/03/10 03:32:12.17
実名さらすって脅迫めいたこともしてなかった?
確か片山がそういう投稿してたよ

404:デフォルトの名無しさん
13/03/10 05:27:56.64
ここもapiスレぽくなってきて良い事だな

405:デフォルトの名無しさん
13/03/10 05:34:18.35
>>392
あなた、あきら君ですよね

406:デフォルトの名無しさん
13/03/10 07:07:06.56
urlにも含まれるアカウント名を指摘して何か意味あんの

407:デフォルトの名無しさん
13/03/10 07:36:37.87
本人乙
他でやれ スレ荒らしどもめ

408:デフォルトの名無しさん
13/03/10 08:44:49.54
荒らしているんじゃなく、キチなりに精一杯スレを盛り上げているんだよ
まー所詮キチ連中だからね

409:デフォルトの名無しさん
13/03/10 08:46:36.63
このキチ成分はC++によるものとして一件落着としよう
さすがC++

410:デフォルトの名無しさん
13/03/10 09:23:52.09
どんだけコンプレックス持ってるんだ

411:デフォルトの名無しさん
13/03/10 09:59:03.57
まじでうざい
片山入室禁止って書いとけ

412:デフォルトの名無しさん
13/03/10 11:37:20.99
0~100の整数を不公平さ無くランダムに並び替えるにはどうするのが効率的ですか?

413:デフォルトの名無しさん
13/03/10 11:39:12.91
std::shafulu

414:デフォルトの名無しさん
13/03/10 11:47:21.15
「不公平さ無く」ってのを明確にしたほうがいい
「ランダムに並び替える」のとはどう違うんだ

415:デフォルトの名無しさん
13/03/10 11:51:40.23
>>414
対象としてる全ての数字が全ての順番に同じ確率で現れうることを不公平さが無いと考えてます

416:デフォルトの名無しさん
13/03/10 12:13:38.13
unsigned a[101]={0,1,2・・・};
unsigned tmp[101];
memcpy(tmp,a,sizeof(unsigned)*101);
for (i = 0; i <101; ++1) a[i+X%100]=tmp[i];

417:デフォルトの名無しさん
13/03/10 12:19:11.23
あ。しっぱい
X=rand();
a[(i+X)%100]=tmp[i];

418:デフォルトの名無しさん
13/03/10 12:51:09.55
>>417
それだと重複しませんか?
並び替えなので当然重複はしてはいけません

419:デフォルトの名無しさん
13/03/10 13:02:49.29
>>416,417みたいな何もわかっていない人のためにstd::shuffleがあるんだけどな

420:デフォルトの名無しさん
13/03/10 13:18:01.44
こうしてカルドセプトはバグったわけか

421:デフォルトの名無しさん
13/03/10 13:33:29.12
ループの外でX取得すれば重複はしないねぇ

422:デフォルトの名無しさん
13/03/10 13:42:42.12
>>421
rotateを実装したいんですね。分かります。

423:デフォルトの名無しさん
13/03/10 14:48:55.05
rand()の分布しだいで415の条件を満たしてしまう不思議

424:デフォルトの名無しさん
13/03/10 14:51:56.14
 int N = 101;
 for (int i = N - 1; i > 0; --i) {
  int j = rand() % (i + 1);
  swap(a[i], a[j]);
 }

425:デフォルトの名無しさん
13/03/10 15:22:56.53
URLリンク(d.hatena.ne.jp)

426:デフォルトの名無しさん
13/03/10 15:26:49.85
>>419
一見正しそうだが実は嘘やよくないやり方を教えるのがC/C++使いの美しい伝統

427:デフォルトの名無しさん
13/03/10 15:32:24.45
そりゃ残念だったな

428:デフォルトの名無しさん
13/03/14 00:17:50.13
リアチョン!

429:デフォルトの名無しさん
13/03/16 10:01:37.85
conio.hでキー入力があったら次のフレームへというようなメインループを作りたいのだけれどどうかくといいかな?
windows.hのSleep()とか使うの?

430:デフォルトの名無しさん
13/03/16 11:32:11.67
>>429
conio.hでキー入力っつーのが分からん

431:デフォルトの名無しさん
13/03/16 11:35:55.18
kbhitとかだろ。
あとはgetcharとか。
それでSleepとか言ってるようじゃまるっきりわかってねーなw

432:デフォルトの名無しさん
13/03/16 11:40:29.91
C++と関係なさそうな話だな

433:デフォルトの名無しさん
13/03/16 11:42:52.70
在日半島人だからな

434:デフォルトの名無しさん
13/03/16 11:55:52.29
conio.hとかMS-DOS時代を思い出すじゃないか懐かしい

435:デフォルトの名無しさん
13/03/16 14:11:46.80
そうですkbhitです
イメージとしては、

//メインループ
while() {

//単位フレームあたりの処理
.....

//もしキー入力があれば次のフレームへ
....

}

のようなことをしたいのでwindows.hのSleepでキー入力があるまでSleepさせておくのかなと思ったので質問しました

436:デフォルトの名無しさん
13/03/16 14:26:56.90
conio.h を使ったゲームとか
今の環境で作る人いないから
何とも言えないと思われ

昔はsleepしなくても動作がもっさりだったので
誰も気にしなかった

437:デフォルトの名無しさん
13/03/16 15:02:46.73
もうすぐ似非UNIXターミナル用意するよりDOS環境用意する方が手間になる時代になあ

438:デフォルトの名無しさん
13/03/16 15:21:35.88
kbhitでやるなら while(!kbhit());
とかで適当に待機しとけばいいだろ
Sleep入れたきゃいれろ

439:デフォルトの名無しさん
13/03/16 15:28:20.78
MS-DOS環境互換のプログラミングなんて
そんなつまらないことしてるなら
Linux環境の方がましじゃねえか

440:デフォルトの名無しさん
13/03/16 15:37:16.67
>>438
すげー懐かしいわwhile(!kbhit());
涙が出そう

441:デフォルトの名無しさん
13/03/16 17:35:16.34
era...

442:デフォルトの名無しさん
13/03/17 10:04:01.04
if( 0&&
  f_in_check == 0 && fmovecheck == 0 && i > 0 && newdepth < 3 * INC_PLY)
{
  処理
}

といった感じの記述があったんですが、これだと
・0
・f_in_check == 0
・i > 0
・newdepth < 3 * INC_PLY

がすべて真のときでないとIF文の中に入らなくて
でも0があったら絶対に中に入らない気がするんですけど違うんでしょうか?

0&&っていうのが、判定のためのなんかのテクニック、ということなんでしょうか……?

443:デフォルトの名無しさん
13/03/17 10:10:19.34
コメントアウトのかわりに0&&でとりあえずその個所を無効にしただけだろ

444:デフォルトの名無しさん
13/03/17 10:27:39.86
#if 0
#endif
は二箇所書く必要があるからそれを嫌ったのかもしれない

445:デフォルトの名無しさん
13/03/17 14:47:39.56
推理ごっこはそれまでにしとけよ白痴

446:442
13/03/17 15:22:42.17
>>443-444
「絶対ここに来ない」というのを逆に利用したんですねきっと
ありがとうございました

447:デフォルトの名無しさん
13/03/17 15:30:59.18
|| が入ってると使えないけどな

448:デフォルトの名無しさん
13/03/17 17:06:02.96
>>456
それ結構やる人いるよバッドマナーだと思うけど
俺なら#if 0使うな

449:デフォルトの名無しさん
13/03/17 17:09:12.26
456が一体何をしたってんだ

450:デフォルトの名無しさん
13/03/17 17:10:53.37
ふっ
これからするのさ

451:デフォルトの名無しさん
13/03/17 17:34:54.09
ごめん。>>448>>442>>446向けだよ
酔っぱらってる

452:デフォルトの名無しさん
13/03/17 19:59:12.40
template< typename T, typename M = Data > struct AAA
{
  struct Data
  {
    int a;
  };
};
クラス内の構造体をテンプレートのデフォルト引数にする方法ないですか?

453:デフォルトの名無しさん
13/03/17 20:04:36.46
無理
素直に外に出しなさい

454:デフォルトの名無しさん
13/03/17 20:08:47.02
はい

455:デフォルトの名無しさん
13/03/17 20:38:24.46
_if < is_void<M> , Data , M >::type
みたいな感じでおk

456:デフォルトの名無しさん
13/03/18 21:04:14.23
make_heapって何に使うんですか

457:デフォルトの名無しさん
13/03/19 01:19:12.98
>>456 ヒープ(データ構造)を作るのに使います。

458:デフォルトの名無しさん
13/03/19 01:46:19.58
>>456
ヒープとしてだけ使うのにmulti_setやmulti_mapではオーバースペックで重いから
vectorとかでヒープを表現するのに使う

459:デフォルトの名無しさん
13/03/20 10:14:37.39
再帰関数(多分木の巡回)で条件をみたしたらthrowで帰る(ルートのラッパーでcatch)みたいなコードを書く同僚を説得してやめさせたいんだけどなんて言えばいいかな?

460:デフォルトの名無しさん
13/03/20 10:18:47.76
>>459
C++例外はもともとエラー通知目的で作られてそう使われてるから、意図が伝わりづらいし
たぶん遅いよ。

461:デフォルトの名無しさん
13/03/20 12:23:43.07
実測だよ実測

462:デフォルトの名無しさん
13/03/20 12:42:30.52
正常系でthrowとかやめて!

463:デフォルトの名無しさん
13/03/20 12:53:24.46
>>459
お前が throw を使わずに高パフォーマンスと高可読性を備えたシンプルなコードを示せば、
そいつは何も言えなくなるだろう。

464:デフォルトの名無しさん
13/03/20 13:05:16.12
発想は面白いとは思うが、効率は・・・

デストラクタがないなら
longjmpしてもいいのだろうか

465:デフォルトの名無しさん
13/03/20 13:12:45.06
正常系でthrowはしないとかいうルールすら時には投げ捨てるべきだ

466:デフォルトの名無しさん
13/03/20 14:07:55.08
やめさせたい理由は?
その手の人は、常識だとか、宗教論争的な理由では動かないんだよね。
理由とその根拠を明示しないと。

467:デフォルトの名無しさん
13/03/20 14:13:24.75
速度要件を満たせば別にイインジャネーノ

468:デフォルトの名無しさん
13/03/20 14:41:52.74
throwで帰るのか
普通returnで返さないの?

469:デフォルトの名無しさん
13/03/20 14:59:11.75
普通はreturnだよ。
でも、「普通」ってのが難しい人って、結構いるんだよね。
個人的には、そういう人も嫌いなはないんだが、会社で出くわすとめんどい。

470:デフォルトの名無しさん
13/03/20 15:01:05.77
returnを繰り返すのは遅いとでも思ってるんじゃないだろうか

471:デフォルトの名無しさん
13/03/20 15:54:16.64
再帰だと一気に全部 return とかできないから、関係箇所全部に終了判定書かなきゃいけない。
throw 一発で書くほうがずっと楽だから、実行効率と開発効率のトレードオフだね。

472:デフォルトの名無しさん
13/03/20 15:55:47.89
>>471
それは再帰を勘違いしてないか?

473:デフォルトの名無しさん
13/03/20 17:00:21.22
俺は再帰関数でthrowを使うという発想はなかったが、エラーでどうしてもやめたいときはいいんじゃない?

474:デフォルトの名無しさん
13/03/20 17:32:17.83
例外とエラーは全然違う概念だから

475:デフォルトの名無しさん
13/03/20 17:34:48.65
どう違っててどう使い分ければいいんすか先輩

476:デフォルトの名無しさん
13/03/20 17:40:49.20
例外のが最適化しやすいね

477:デフォルトの名無しさん
13/03/20 17:52:26.06
>>475
例外は、一般的には通常の処理の流れを変えて別の処理に移る仕組みを指す。
C++含む多くの言語ではエラーの通知を主な目的として言語機能に反映されており、
当然エラー通知に使うと便利。

基本的にエラー通知にだけ使っておけばいいけど、自己責任で妙な使い方もできるだろうし、
その中にはもしかすると有用だったり面白い使い方もあったりしないとも言い切れない。

そんなわけで、簡単な答えとしては「エラー通知以外に使うな」となる。

478:デフォルトの名無しさん
13/03/20 17:59:09.95
例外を使わない方法だと「再帰の下の階層で答えが見つかったか」を階層分確かめないといけない
また、答えを下層からルートまで運ぶのに返り値でリレーしなければならないから無駄が多い

479:デフォルトの名無しさん
13/03/20 18:06:52.15
どっちでもいいけど実例としてコード書いてくれ

480:デフォルトの名無しさん
13/03/20 18:08:34.55
その無駄は本当に無駄になっているのかよ
大抵無駄な最適化だよ

481:デフォルトの名無しさん
13/03/20 18:20:12.61
例外はエラーのためだけなんて変な固定概念に束縛されんなよ

482:デフォルトの名無しさん
13/03/20 18:23:38.44
このシステムはメモリーを出来る限り多く確保する方針であるという作り方なら、
メモリー確保を試みた結果「確保できませんでした」となる頻度が高く
そのようなシステムではbad_allocの例外は必要ない。
エラーだからといって例外とは限らない。

483:デフォルトの名無しさん
13/03/20 18:25:10.20
「例外」は「通知手段」じゃない
これわからない奴がエラー通知に使うんだな

484:デフォルトの名無しさん
13/03/20 18:33:49.31
例外とエラー処理は違うという話もわからんではないが
例外はエラー処理でいいだろ。

485:デフォルトの名無しさん
13/03/20 18:39:34.14
>>478
その認識は再帰を理解していないと思われる

486:デフォルトの名無しさん
13/03/20 18:56:39.24
っていうか、例外って積極的に使うようなものじゃないよね?
ときどき、catch使えばifによるエラー分岐が不要になってその分効率よくなるとか書いてあるけど、
throw()とかが役に立たない今はthrowなんてプログラムを不安定にするだけだから、使わないし使わせない。

487:デフォルトの名無しさん
13/03/20 19:10:54.28
よほど特殊な実装出もない限り、throw と catch より if の方が効率良いけどな。
ま、結局の所、実測してみないと何とも言えないけど。

488:デフォルトの名無しさん
13/03/20 19:11:17.54
>>486
逆だろ
例外はいつでも飛んでくるということを前提にしないとダメ

489:デフォルトの名無しさん
13/03/20 19:28:47.43
>>486
どういう理屈でthrowがプログラムを不安定にするなんてことになるの?

490:デフォルトの名無しさん
13/03/20 19:32:48.96
深い再帰で
各レイヤーにifを入れて分岐させるよりは
throwのlongjumpに任せて例外時のみ判断が入るようにした方が高速

491:デフォルトの名無しさん
13/03/20 19:38:04.66
>>490
どれくらい速いの?

492:デフォルトの名無しさん
13/03/20 19:38:14.55
throwするかどうかをif使わずに分岐させるってことか?

493:デフォルトの名無しさん
13/03/20 19:40:14.84
signalを使え…やっぱりいい

494:デフォルトの名無しさん
13/03/20 20:20:09.87
>>490 測定コードと環境は?

495:デフォルトの名無しさん
13/03/20 21:01:22.17
別に例外使ってシンプルになるならどんな使い方だってやればいい
自分の足も他人の足も撃たないように理解して説明も出来るならだが

496:デフォルトの名無しさん
13/03/20 21:18:15.23
あれ
exception速いな

497:デフォルトの名無しさん
13/03/20 21:25:08.24
気になったのでコード書いてみました
URLリンク(codepad.org)
環境はWindows7 64bt、 CPU はAthlon64x2 3800+
コンパイラはVisualStudio2012、最適化はO2、バイナリは64bit版を生成
結果はこうでした
Normal版 : 326 ミリ秒
Exception版 : 1346 ミリ秒

498:デフォルトの名無しさん
13/03/20 21:31:01.14
>>487
最近は例外のが早い

499:デフォルトの名無しさん
13/03/20 21:33:46.25
>>490
そろそろコードを見せてくれませんか?

500:デフォルトの名無しさん
13/03/20 21:35:25.54
>>498
冗談やめてくれ

501:デフォルトの名無しさん
13/03/20 21:40:59.02
>>500
いやまじな話な
例外を使わないとifを繰り返すコストがあるが
例外はもう最近は正常系ではゼロコストだか、

502:デフォルトの名無しさん
13/03/20 21:41:35.17
例外が速いって言ってる人は大抵数行のコードだけで比較して言ってるのばっかり

503:デフォルトの名無しさん
13/03/20 21:42:46.31
例外なんて積極的に使うもんじゃない

504:デフォルトの名無しさん
13/03/20 21:43:41.18
gccもいつのバージョンからか、例外使うコードの正常系はオーバーヘッドがゼロになったんだよな

505:デフォルトの名無しさん
13/03/20 21:44:25.42
正常系にthrowを使う話をしてたんじゃなかったのか

506:デフォルトの名無しさん
13/03/20 21:45:06.30
C/C++プログラマに例外は理解できない
Javaをやれ

507:デフォルトの名無しさん
13/03/20 21:45:15.26
ま、例外の方が速いなら、自己責任の最適化として使えばいいんじゃね?
例外やエラー時に、exception を使う事自体には何の問題もないと思うが、そこに速度の話を持ち込むのはいかがなものかと思うぞ。
正常系の終了処理とかでexception を使うとか言うのは、会社ではやめた方がいいと思う。

508:デフォルトの名無しさん
13/03/20 21:46:22.82
>>501
実際に throw されるパスの話をしているわけだが。

509:デフォルトの名無しさん
13/03/20 21:46:28.24
例外を制御に使うとただのgotoでしかないんですがそれは

510:デフォルトの名無しさん
13/03/20 21:47:10.69
Pythonとかに喧嘩売ってんの?
もう固定観念で例外を活用しないてのは素人のやることだよ

511:デフォルトの名無しさん
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とか言い出すに500円

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
今度は拡大解釈ですかw

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づつリークするけど月1でリブートするから
対応しなくてお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


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch