スレッド: [cppll:9323] インスタンスを生成して返す関数内部で例外が発生した時のルール

こんにちは。中山です。
＃またしてもしょーもない質問かもしれませんが、
＃一応「2929」あたりから始まるスレを見ましたが、、、これは例外に関する話題でした。
＃これも相当参考になりました。

下記のように、インスタンスを生成して返す関数があります。

CHoge *CreateNewInstance( int type );

この関数内部で例外が発生した場合、、
もしくは、引数間違いとかがあって、インスタンスを返したくない場合、
下記の2通り思いつくのですが、どちらが良いでしょう?
・NULLを返す。
・例外を発生させる。
※場合によってはNullObjectを返すこともあると思いますが。

今、私は下記のように「NULLを返す」ようにしています。

------------------------------------------------------------------------------------
CHoge *CreateNewInstance( int type )
{
   CHoge *ret = NULL;

   try{
       auto_ptr<CHoge> temp( new CHoge );

       if( type > TYPE_MAX ) throw CException( E_TYPE_IS_INVALID );

       //データセットとか何かの処理(例外が発生するかも)

       //全ての処理に成功したら、インスタンスを返す。
       ret = temp.release();
   }catch( CException &e ){
       //何かしらの例外が発生したら
       //「auto_ptr<CHoge> temp」のスコープが外れて開放される。

       //ここで再throwするべき？
       // throw;
   }catch( ... ){
       //何かしらの例外が発生したら
      //「auto_ptr<CHoge> temp」のスコープが外れて開放される。
   }

   return ret;
}
------------------------------------------------------------------------------------

好み、ポリシーの問題になりそうですが、、、どっちが主流かな?と皆さんの意見を聞かせてください。
他の会社に行った時に通用するように(笑)
それから、今の社内のコードのルール化を進めるための参考とさせていただくために。。
よろしくお願いします。

<余談>
　さて、またしても、私のコードを見て同じプロジェクトに入りたくなくなった方の挙手願います(笑)
　というか、今まで自分が書いたコードが、他者にどう見えるのか意識したことがなかったのですが、
　最近、自分のコードが読みやすいのか？一般的なやり方なのか？が気になり始めました。
　プロ集団が集まるこのMLリストに今後も自分のコードを晒させていただきたいと思いますが、
　迷惑じゃないでしょうか？
</余談>


"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~
中山 剛史 <naka@...>
"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~

Takefumi Nakayamaさんの<20030807152156.7946.NAKA@reedrex.co.jp>から
>好み、ポリシーの問題になりそうですが、、、どっちが主流かな?と皆さんの意見を聞かせ
>てください。

　私は NULL を返すのがほとんどですね。どちらかっていうと C のお仕
事が多いので、癖になっています。

　ただ、最近思うのが多重に呼び出される関数の内部でエラーが起きた
とき、NULL を返すとなると、ちとめんどい事ですね。

　そういう場合は例外の方が楽なんでしょうね。

--
電柱一家
mailto:cppll@...
http://denchu.jp/

こんにちは。中山です。

> 　ただ、最近思うのが多重に呼び出される関数の内部でエラーが起きた
> とき、NULL を返すとなると、ちとめんどい事ですね。

そうなんですよね。
結局
if( (pHoge = CreateNewInstance( type )) == NULL )
みたいなことやらなあかんのか？
って話になると、例外の方が楽には楽なんですが、
「例外はgotoかよ？」みたいな話題が以前の「2929」あたりのスレであったので、、
いや、中身はまだきちんと読んでないんですけど(^^;)

他の方の意見も多く聞かせていただきたいです。

"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~
中山 剛史 <naka@...>
"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~

重松です。こんにちは。

> 　そういう場合は例外の方が楽なんでしょうね。

理由を返せるので、例外のほうが便利な気もします。
というわけで、例外に一票。

で、環境に依存した話になるのかもしれませんが、
例外にはどの程度コストがかかるものなのでしょうか。
投げた場合も、平穏だった場合も。

http://www.microsoft.com/japan/developer/library/vccore/_core_exception_handling_overhead.htm

辺りを見ると、スイッチ (オプション) でコストが変わるようにも読めます。
# 参照せよとある本はあいにく持ってません。。。

--
Osamu Shigematsu <m5issige@...>

επιστημηです。

--- "[cppll:9330] Re: インスタンスを生成して返す関数内部で例外が発生した時のルール" / Osamu Shigematsu ---

>例外にはどの程度コストがかかるものなのでしょうか。
>投げた場合も、平穏だった場合も。

例外飛んだときにたどり着くトコをスタック上に載せて
おくことになろうかと思います。だから例外が飛ぼうが
飛ぶまいが、この刻印を打つのにコストかかりそ。

-----:-----:-----:-----:-----:-----:-----:-----:-----:-----
FUKUDA (episteme) Fumiki -- magical, but never a magic...

重松です。こんにちは。

> 例外飛んだときにたどり着くトコをスタック上に載せて
> おくことになろうかと思います。だから例外が飛ぼうが
> 飛ぶまいが、この刻印を打つのにコストかかりそ。

そんな気がするんですが、以前どこかで、多分、CodeWarrior 関連だったと
思うのですが、例外が発生しなれば、まったくコストはかからない、
というようなのを呼んだ記憶があります。
# Google 先生に聞いてみてますが、キーワードが悪いのか、
# なかなかヒットしません...。

確かに、めったに発生しないから例外なわけで
それでコストがかかるのはかなりばかばかしい話だと思って、
妙に納得した気がするのですが、わざわざそれが語られるということは、
そうでない環境もたくさんあったりして、コストも案外かかるんだと、
それはそれでやっぱり NULL かしらと思ったりしました。

--
Osamu Shigematsu <m5issige@...>

樋口です。

On Thu, 07 Aug 2003 17:32:22 +0900
Osamu Shigematsu <m5issige@...> wrote:

> > 例外飛んだときにたどり着くトコをスタック上に載せて
> > おくことになろうかと思います。だから例外が飛ぼうが
> > 飛ぶまいが、この刻印を打つのにコストかかりそ。
>
> そんな気がするんですが、以前どこかで、多分、CodeWarrior 関連だったと
> 思うのですが、例外が発生しなれば、まったくコストはかからない、
> というようなのを呼んだ記憶があります。

VC++の場合、例外が通り抜けた場合に後始末が必要なフレームには刻印を打つ
るコードが常に生成されるようです。よって例外が飛ばなくても実行時コスト
が少しかかります。

GCCの場合、それらしきコードは一切生成されず、そのかわり謎の構造のテー
ブルが生成されます。例外が飛ばない場合には、実行時のコストはかかりま
せん。

吐いたコードを読む限りではこのような感じなのですが、どこかでVC++でも
事実上コストがかからないと書いてあったような気がします。

例外が飛んだ場合のコストは実験してみないとわかりませんが、やはりトレー
ドオフがあるのではないでしょうか。

重松です。こんにちは。

> VC++の場合、例外が通り抜けた場合に後始末が必要なフレームには刻印を打つ
> るコードが常に生成されるようです。よって例外が飛ばなくても実行時コスト
> が少しかかります。
>
> GCCの場合、それらしきコードは一切生成されず、そのかわり謎の構造のテー
> ブルが生成されます。例外が飛ばない場合には、実行時のコストはかかりま
> せん。
>
> 吐いたコードを読む限りではこのような感じなのですが、どこかでVC++でも
> 事実上コストがかからないと書いてあったような気がします。

GCC の場合には、逆説的にいえば、そのテーブルがロードされるコストが
かかってしまいますね。そして、それは例外発生時に払われるので、
VC 方式に比べて、例外時のコストが大きいと、理解してよいでしょうか?

> 例外が飛んだ場合のコストは実験してみないとわかりませんが、やはりトレー
> ドオフがあるのではないでしょうか。

基本的には、トレードオフにはあると思いますが、例外の発生頻度が
少ない場合 (基本的は、例外が発生することはまれなはず) に、
有利なものの法が優れている気がします。

--
Osamu Shigematsu <m5issige@...>

Message-Id: <20030807200832.E5AE.M5ISSIGE@mr.hitachi-medical.co.jp>
 Date:       Thu, 07 Aug 2003 20:12:21 +0900
 From:       Osamu Shigematsu <m5issige@...>
 Subject:    [cppll:9339] Re: インスタンスを生成して返す関数内部で例..

 | 重松です。こんにちは。
 |
 | > VC++の場合、例外が通り抜けた場合に後始末が必要なフレームには刻印を打つ
 | > るコードが常に生成されるようです。よって例外が飛ばなくても実行時コスト
 | > が少しかかります。
 | >
 | > GCCの場合、それらしきコードは一切生成されず、そのかわり謎の構造のテー
 | > ブルが生成されます。例外が飛ばない場合には、実行時のコストはかかりま
 | > せん。
 | >
 | > 吐いたコードを読む限りではこのような感じなのですが、どこかでVC++でも
 | > 事実上コストがかからないと書いてあったような気がします。
 |
 | GCC の場合には、逆説的にいえば、そのテーブルがロードされるコストが
 | かかってしまいますね。そして、それは例外発生時に払われるので、
 | VC 方式に比べて、例外時のコストが大きいと、理解してよいでしょうか?

例外テーブルの大きさがどのくらいになるか調べたことはないのですが
ロードするコストよりも例外発生時のテーブルを検索するコストに
支配されるとおもいます。
検索コストは関数の数をNとした場合にテーブルを二分探索するとO(log N)。

昔gccに例外処理が入りたてのころコードを読んだ記憶だと、
throwすると例外が発生したプログラムカウンタから
そのスタックフレームのunwind前にすべき処理をみつけだして実行、
スタックをunwindして例外がcatchされるかtopにぶるかるまでグルグルまわす、
だったとおもいます。

 |
 | > 例外が飛んだ場合のコストは実験してみないとわかりませんが、やはりトレー
 | > ドオフがあるのではないでしょうか。
 |
 | 基本的には、トレードオフにはあると思いますが、例外の発生頻度が
 | 少ない場合 (基本的は、例外が発生することはまれなはず) に、
 | 有利なものの法が優れている気がします。
 |
 | --
 | Osamu Shigematsu <m5issige@...>
 |
 |
 | --[PR]------------------------------------------------------------------
 | 【 FreeML ユーザー登録してますか？】
 | 　　・メールアドレスとパスワードのカンタン登録！
 | 　　・ニックネームもつけられるし、WEBメールも使える！
 | 　　・MLだってカンタンに作れちゃう！
 | ▼ いますぐ登録！ => http://click.freeml.com/ad.php?id=934686
 | ------------------------------------------------------------------[PR]--
 | <GMO GROUP> Global Media Online  www.gmo.jp
 |

樋口です。

On Thu, 07 Aug 2003 22:33:08 +0900 (JST)
KOIE Hidetaka (鯉江英隆) <hide@...> wrote:

>   | GCC の場合には、逆説的にいえば、そのテーブルがロードされるコストが
>   | かかってしまいますね。そして、それは例外発生時に払われるので、
>   | VC 方式に比べて、例外時のコストが大きいと、理解してよいでしょうか?
>
> 例外テーブルの大きさがどのくらいになるか調べたことはないのですが
> ロードするコストよりも例外発生時のテーブルを検索するコストに
> 支配されるとおもいます。
> 検索コストは関数の数をNとした場合にテーブルを二分探索するとO(log N)。

簡単なコードを書いてVC++とgccで計測してみました。
テストの内容は、ほとんど何もしない関数を1億回呼び出すだけです。
「例外を投げる」ほうは、その関数の中で例外を投げ、ループの内側で
catchします。どちらもほぼ限界まで最適化をかけてあります。
ループのアンロールはしていません。

VC++
例外投げない   0.44秒
例外投げる   212.05秒

gcc
例外投げない   0.35秒
例外投げる   966.55秒

どちらのほうが嬉しいかは微妙なところです。

しかし例外処理がこれほど遅いものだとは知りませんでした。

今野です

On Fri, 8 Aug 2003 00:27:13 +0900
Akira Higuchi <a-higuti@...> wrote:
> 簡単なコードを書いてVC++とgccで計測してみました。

ぜひ、コードを載せてください。

--
Shu KONNO
http://owa.as.wakwak.ne.jp/zope

樋口です。

On Fri, 8 Aug 2003 00:49:40 +0900
Shu KONNO <owa@...> wrote:

> On Fri, 8 Aug 2003 00:27:13 +0900
> Akira Higuchi <a-higuti@...> wrote:
> > 簡単なコードを書いてVC++とgccで計測してみました。
>
> ぜひ、コードを載せてください。

------- exptiming.cpp --------------------------------------

#include <time.h>
#include <stdio.h>
#include "exptiming.h"

int foo_destr_count = 0;

struct foo {
 foo(int x) : v(x) { }
 ~foo() { foo_destr_count += v; }
 int v;
};

void exptest1()
{
 foo f(1);
 unknown_func1();
}

void exptest2()
{
 foo f(1);
 unknown_func2();
}

struct timing {
 timing() : start_cl(::clock()) { }
 ~timing() {
   printf("%f\n", double(::clock() - start_cl) / double(CLOCKS_PER_SEC));
 }
 clock_t start_cl;
};

int main()
{
 const size_t loopmax = 100000000;
 {
   timing t;
   for (size_t i = 0; i < loopmax; ++i) {
     try {
       exptest1();
     } catch (...) {
     }
   }
 }
 {
   timing t;
   for (size_t i = 0; i < loopmax; ++i) {
     try {
       exptest2();
     } catch (...) {
     }
   }
 }
 return 0;
}

------- exptiming.h ----------------------------------------

void unknown_func1();
void unknown_func2();

------- unknown.cpp ----------------------------------------

#include "exptiming.h"

int dummy_count = 0;

void unknown_func1()
{
 ++dummy_count;
}

void unknown_func2()
{
 ++dummy_count;
 throw 1;
}

------------------------------------------------------------

使用した最適化オプションは、
VC7.1: /Ox /Og /Ob2 /Oi /Ot /Oy
gcc3.3: -O3 -fomit-frame-pointer
です。
unknown_func1, unknown_func2は、例外を投げるかどうかをコンパイル時に
判断できないようにするために別ファイルに分けてあります。exptest1と
exptest2は、VCとgccのいずれもインライン展開されてループの中に埋め込
まれています。VCの、例外のための「刻印を打つ」オーバヘッドはインラ
イン展開によってかなり軽減されているようです。

重松です。こんにちは。

> VCの、例外のための「刻印を打つ」オーバヘッドはインラ
> イン展開によってかなり軽減されているようです。

という点ですが、元の質問からして、当該関数がインライン展開される
可能性はそれほど高くないと思いますし、virtual だったりすると、
インラインに展開されること自体が期待できないので、
このオーバヘッドの軽減は、例外を NULL として返すのか、
throw するのか、この場合のみで考えるのは危険な気もしたりします。

にしても, gcc の例外送出時のコストは大きいですね。

具体的な数値は大変参考になります。
情報 (ソースも)、ありがとうございます。

--
Osamu Shigematsu <m5issige@...>

Tietew です。

On Thu, 07 Aug 2003 17:04:19 +0900
In article <200308070811.h778BWQ15266@mailsv3.nec.co.jp>
[[cppll:9331] Re: インスタンスを生成して返す関数内部で例外が発生した時のルール]
FUKUDA Fumiki <fukuda.fm@...> wrote:

> >例外にはどの程度コストがかかるものなのでしょうか。
> >投げた場合も、平穏だった場合も。
>
> 例外飛んだときにたどり着くトコをスタック上に載せて
> おくことになろうかと思います。だから例外が飛ぼうが
> 飛ぶまいが、この刻印を打つのにコストかかりそ。

確かにコストはかかるけど，せいぜいポインタ３〜４つぶんをスタック
に積んだり下ろしたりするだけなので，場合によっては毎回エラー判定
するよりも安かったりしそうです。

例外が投げられたときは，例外スタックを戻りつつスタックを巻き戻す
操作が入るので，結構高コストですが，例外を使わなくても結局自動変
数を破壊しながら登ってゆくことになるので，例外オブジェクトの生成
と型判定処理の分だけコスト増ということになるんじゃないかと。


—[ Tietew ]——— tietew@... / tietew@... ——————
■Tietew Windows Lab.                        http://www.tietew.net/
★C++:language&libraries過去ログ&なまず http://www.tietew.jp/cppll/
PGP fingerprint: 26CB 71BB B595 09C4 0153  81C4 773C 963A D51B 8CAA

いつもお世話になっております。
安藤＠恵比須情報です

> 下記のように、インスタンスを生成して返す関数があります。
>
> CHoge *CreateNewInstance( int type );
>
> この関数内部で例外が発生した場合、、
> もしくは、引数間違いとかがあって、インスタンスを返したくない場合、
> 下記の2通り思いつくのですが、どちらが良いでしょう?
> ・NULLを返す。
> ・例外を発生させる。
> ※場合によってはNullObjectを返すこともあると思いますが。
>

いろんなアプリで使いまわしされるコードならNULLを返す方がいいと思います。
場合によっては例外は使わないでって事もあると思うから。
例外を返したい場合はCreateNewInstanceを呼び出すところで発生させるって感じ
で。
int CreateNewInstance( int type, CHoge** instance);
でエラー情報を返すってしておけば呼び出し側はエラーコードから例外種別を特定し
て
発生させることもできるし。


> 好み、ポリシーの問題になりそうですが、、、どっちが主流かな?と皆さんの意見
を聞かせてください。
> 他の会社に行った時に通用するように(笑)

他の会社に行くことを考えるなら凝ったＣ＋＋のソースは書かない方が吉かも。
少なくとも僕はＳＴＬや例外を常用しているような会社の仕事はしたことが無いです
（サポートしてる
コンパイラを使ったプロジェクトでも）。ここのＭＬに達人がいっぱいいるだけで世
間ではそんなに標
準Ｃ＋＋ライブラリやＣ＋＋の機能は知られていないと思う。

# 時にはベタＣのようなソースコードを書いてストレスがたまることもあるからＣ＋
＋で自分の使う
# ツールを作ってうさ晴らしをする。


-------------------------------
安藤 敏彦(ANDO Toshihiko)
Mail: andochin@...

いさぽんです。こんにちわ。
そして始めましてですm(_ _)m

> 好み、ポリシーの問題になりそうですが、、、どっちが主流かな?と皆さんの意見
を聞かせてください。

　私の場合ですが、通常NULLを返しますが、引数のミスなど関数の呼び出し側に不具
合がある場合は
例外を返しています（例えば、０か１を渡さなければならない関数に対して２を渡し
た場合など）。

　このような場合、関数の使い方を勘違いしてる可能性が多いので、例外を返したほ
うが分かりやすい
かなぁ…ということで（＾＾；

　例外起きたら「あ、関数のパラメータ間違ってたか！」と言う感じです。

----------------------------------------------------------------------------
--------
CHoge* CreateNewInstance(int type)
{
   // 引数に間違えがあるかチェック
   if (type > TYPE_MAX)
   {
     // 「そんな呼び出し方しちゃダメです」という意味を込めて例外
     throw CException( E_TYPE_IS_INVALID );
   }

   CHoge*  pResult = 0;
   try {
     // インスタンス生成
   } catch (...) {
     // エラー処理
   }
   return pResult;
}
----------------------------------------------------------------------------
--------

---
isapon : mail@...

重松です。こんにちは。

> 　私の場合ですが、通常NULLを返しますが、引数のミスなど関数の呼び出し側に不具
> 合がある場合は
> 例外を返しています（例えば、０か１を渡さなければならない関数に対して２を渡し
> た場合など）。
>
> 　このような場合、関数の使い方を勘違いしてる可能性が多いので、例外を返したほ
> うが分かりやすい
> かなぁ…ということで（＾＾；
>
> 　例外起きたら「あ、関数のパラメータ間違ってたか！」と言う感じです。

例外って、そういう使い方するものですか?

私の感覚では、

       assert(arg == 0 || arg == 1); // バグなら即死

ですが...。

# バグは例外で処理するものではないと思ふ...。

--
Osamu Shigematsu <m5issige@...>

こんにちは、炎羅です。

On Thu, 07 Aug 2003 17:34:43 +0900
At [cppll:9335] Re: インスタンスを生成して返す関数内部で例外が発生した時のルール
Osamu Shigematsu <m5issige@...> Wrote:

>        assert(arg == 0 || arg == 1); // バグなら即死
> # バグは例外で処理するものではないと思ふ...。

assert関数はスタックアンワインドしてくれないんじゃないでしょうか？
abort関数に行き着いて、後処理を全くせずにterminateだったような覚えが
あります。
そうなると、メモリリークやリソースリークを引き起こす恐れがあるのでは
ないでしょうか？

そんなわけでassert関数の代用として、仕方なく例外を使う事はあると思います。
ただVC++系の場合例外が飛んでも非常に分かりづらいので、何かラッパ関数を
作って、親切なダイアログを出した方がいいかもしれませんけど^^;

■ Written by 炎羅 (enra@...) ■

小野@名古屋大学 です.

<20030807203733.6F67.ENRA@mail.interq.or.jp>の記事において
enra@...さんは書きました。
enra> >        assert(arg == 0 || arg == 1); // バグなら即死
enra> > # バグは例外で処理するものではないと思ふ...。
enra> assert関数はスタックアンワインドしてくれないんじゃないでしょうか？
enra> abort関数に行き着いて、後処理を全くせずにterminateだったような覚えが
enra> あります。
enra> そうなると、メモリリークやリソースリークを引き起こす恐れがあるのでは
enra> ないでしょうか？
「まともな」OS ならプロセスが終了したときにリソースを全て回収する
のでは? だから, メモリリークはしないはず.

ただ, ファイルのロックとかで問題になることはあるかも.
# ロックしちゃったまま終了して「アンロックできね〜」ってことはあ
# りうる.
--
名古屋大学大学院 情報科学研究科 計算機数理科学専攻
小野 孝男

こんばんは。中山です。

enra> >        assert(arg == 0 || arg == 1); // バグなら即死
enra> > # バグは例外で処理するものではないと思ふ...。

私も、この考え方に賛成です。
ですから、客先リリース時には、assertに引っかかる部分があってはならないはずだし、
そういう意味では、assert後のメモリーリークに関して議論する必要はないかと思います。

でも、例えば、DBのあるフィールドの値によって挙動を変えるインスタンスを返す処理の場合、
仕様変更時にデータパッチを当て忘れて、不正な値が関数に渡されてしまう場合もありますね。
そういう場合は、
(1)例外で処理して、然るべき結果をユーザに示す
(2)データパッチを当てる必要が無いようにコードを書き直す
のどちらかで対処するべきだと考えます。

(2)をやりすぎるとコードがぐちゃぐちゃになるので、NullObjectを返すか、
共通のエラー処理を行うインスタンスを返すか…

どうでしょう？

------------------------------------------------------
CHoge *ret = NULL;
switch( type ){
case 1:
 ret = new CHogeDog
 break;
case 2:
 ret = new CHogeCat
 break;
default:
 ret = new CHogeError
 break;
}
------------------------------------------------------

"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~
中山 剛史 <naka@...>
"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~^"~

重松です。こんにちは。

> ですから、客先リリース時には、assertに引っかかる部分があってはならないはずだし、
> そういう意味では、assert後のメモリーリークに関して議論する必要はないかと思います。

そういう意味で、assert() は単に普通の (?) ものを引っ張ってきました。

ただ、こういうのって、自分たち開発側でテストを尽くしたつもりでも、
お客さんのところでは、予測もしなかった使い方をして
問題が発生したりするし、なかなか難しいものです。

なので、実際には、ASSERT() というマクロで、引っかかると、
ダイアログを出して、ある程度の死亡位置を確認できるように
工夫したりはしています。

けど、工業製品の場合、ソフトのバグ以外に、装置の故障、もあるわけで、
難しいです。

Microsoft Car じゃないけど、ぶつかりましたがエアバックを作動しますか?
と聞かれて はい をクリックしないと、エアバックが作動しないのも困るし、
壊れるにしても、ブレーキが利かなくなるのではなくて、
ブレーキを解除できなくなるような、安全側に振った壊れ方とか、
死ぬときにも、きれい/安全な死に方を考慮しないといけないケースも
多々あるかと。

--
Osamu Shigematsu <m5issige@...>

Tietew です。

On Thu, 7 Aug 2003 20:43:50 +0900
In article <030807204350.M0115732@flame.hirata.nuee.nagoya-u.ac.jp>
[[cppll:9341] Re: インスタンスを生成して返す関数内部で例外が発生した時のルール]
takao@... (Takao Ono) wrote:

> enra> そうなると、メモリリークやリソースリークを引き起こす恐れがあるのでは
> enra> ないでしょうか？
> 「まともな」OS ならプロセスが終了したときにリソースを全て回収する
> のでは? だから, メモリリークはしないはず.

メモリリークといえば free-on-exit 論争（読んでないけど…

# 終了にやけに時間がかかると思ったら，大量の要素を抱えた map の
破壊に時間がかかっていた罠，とか。


> ただ, ファイルのロックとかで問題になることはあるかも.
> # ロックしちゃったまま終了して「アンロックできね〜」ってことはあ
> # りうる.

ロックもリソースのうちだから，まともなOSならロックも解放しますね。


というか，Segmentation Fault とかしちゃったら，外部から kill さ
れちゃったら，メモリ不足でカーネルが kill しちゃったら，etc，オ
ブジェクトの回収なんぞ望むべくもないわけで，「終了時」のリソース
リークをそこまで気にすんな，と言いたくもある。

# リリースビルドで気にしたい，というなら判るけど，
# assert ってデバッグビルドだし。

—[ Tietew ]——— tietew@... / tietew@... ——————
■Tietew Windows Lab.                        http://www.tietew.net/
★C++:language&libraries過去ログ&なまず http://www.tietew.jp/cppll/
PGP fingerprint: 26CB 71BB B595 09C4 0153  81C4 773C 963A D51B 8CAA

道化師です。

【[cppll:9335] Re: インスタンスを生成して返す関数内部で例外が...】
> assert(arg == 0 || arg == 1); // バグなら即死

スレの趣旨とは関係ないけど、assert 内でこのような || の使い方
は避けませう。このような場合は２つの assert に分割すること推奨
いたしますです。

□■□■                  Wraith the Trickster                  □■□■
■□■□ 〜I'll go with heaven's advantage and fool's wisdom.〜 ■□■□