standard library functions
Kusakabe Youichi
どこかにないですか?
(webをあちこちあさってみたのですが、一部だけだったり、古かったりで、
案外みつからないのです)
--
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
IIJIMA Hiromitsu
> C99の標準ライブラリー関数の一覧って
> どこかにないですか?
>
> (webをあちこちあさってみたのですが、一部だけだったり、古かったりで、
> 案外みつからないのです)
C90 との差分になりますが、http://seclan.dll.jp/c99d/ なんていかがですか？
あとは ISO の規格書の原文を入手するしかないのかなあ。
＃もう JIS になってましたっけ？JIS になってれば PDF で読めそうなんですが。
========================================================================
飯嶋 浩光 / でるもんた・いいじま http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp
tabe
田部です。
別件ですが、Ｃ９９仕様での、
かっちょいい、
デバッグ文（可変引数マクロ）
はどう書けば、良いのでしょうか？
＃「最適化すると消えてなくなる・は・ず・」は無しで。
最適化しなくても、非DEBUG時に消えて欲しい。
イメージ：
#if DEBUG
#define SNAP(........ ここ！
#endif
int main(void)
{
SNAP("%s\n", __FILE__) ;
SNAP("%s:%d\n", __FILE__,__LINE__) ;
SNAP("%s:%d:%s\n",__FILE__.__LINE__,__FUNCTION__) ;
return 0 ;
}
--
以上
Shinji KONO
In article <bfls2e$kej$1...@bgsv5647.tk.mesh.ad.jp>, "tabe" <ta...@mug.biglobe.ne.jp> writes
> ＃「最適化すると消えてなくなる・は・ず・」は無しで。
> 最適化しなくても、非DEBUG時に消えて欲しい。
最近、読んだ本 Writing Solid Code にも「assert を多用し、出
荷時には消す」みたいな話が載ってましたが、根本的に間違ってい
るんじゃないかな。
debug code が全体の10%を越えることは絶対にあり得ないです。
で、if 文で切れば、大半はbranch predictionに引っかかって、
全体のパフォーマンスには影響しないと思う。
ある程度の大きさのプログラムならば、「どうやってデバッグする
か」「どうやってテストするか」ってのを前もって考えるべきで、
そのhookとして、debug code があるべきなんじゃないかな。
たとえば GNU malloc なんかは、debug code (っていうのか?)
built-in ですよね。
---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)
KATAYAMA Yoshio
> 別件ですが、Ｃ９９仕様での、
> かっちょいい、
> デバッグ文（可変引数マクロ）
> はどう書けば、良いのでしょうか？
> ＃「最適化すると消えてなくなる・は・ず・」は無しで。
> 最適化しなくても、非DEBUG時に消えて欲しい。
>
> イメージ：
> #if DEBUG
> #define SNAP(........ ここ！
> #endif
#if DEBUG
#define SNAP(...) fprintf(stderr, __VA_ARGS__)
#else
#define SNAP(...)
#endif
> int main(void)
> {
> SNAP("%s\n", __FILE__) ;
> SNAP("%s:%d\n", __FILE__,__LINE__) ;
> SNAP("%s:%d:%s\n",__FILE__.__LINE__,__FUNCTION__) ;
s/\./,/
--
片山＠ＰＦＵ
tabe
From: "Shinji KONO" <ko...@ie.u-ryukyu.ac.jp>
> 最近、読んだ本 Writing Solid Code にも「assert を多用し、出
> 荷時には消す」みたいな話が載ってましたが、根本的に間違ってい
> るんじゃないかな。
この本は、以前、fj.comp.lang.c
で紹介されたので、読みました。
読んでも損は無いかと思いますが、
ASSERT()の事ばかり書いていた記憶があります。
gcc,lint,splint等の言語処理系は、
ａｓｓｅｒｔを多用して出荷？して、
「内部エラーです、ごめんちゃい」してますね。
これは、これで良い姿勢だと思います。
しかし、
・原子力発電所の制御
・航空機の制御、
・自動車エンジンの制御
等で、ａｓｓｅｒｔを有効にして出荷する事が、
良い事なのか、
悪い事なのか、
私にはわかりません。
> debug code が全体の10%を越えることは絶対にあり得ないです。
> で、if 文で切れば、大半はbranch predictionに引っかかって、
> 全体のパフォーマンスには影響しないと思う。
河野さんのお考えは、
http://www.catnet.ne.jp/kouno/c_faq/c10.html#26
の最後にある、
「それよりは適切に定義された方法で
可変個の引数を扱う特製の関数を 作るほうがよい」と言う事でしょうか？
そうで、あれば、私も同意します。
私が、消えて無くなるＳＮＡＰ文(=デバッグプリント文）を望んだのは、
SNAP("%s:%d:%s\n",__FILE__.__LINE__,__FUNCTION__) ;
を、
ｃ８９仕様で、
#if DEBUG
#define SNAP printf
#else
#define SNAP
#endif
と、定義した場合、
非ＤＥＢＵＧ時
（"%s:%d:%s\n",__FILE__.__LINE__,__FUNCTION__） ;
となり、
ｇｃｃ -Wall -W 等が、
null effect(無効な記述）
の警告をわんわん出してうるさいからです。
> ある程度の大きさのプログラムならば、「どうやってデバッグする
> か」「どうやってテストするか」ってのを前もって考えるべきで、
> そのhookとして、debug code があるべきなんじゃないかな。
> たとえば GNU malloc なんかは、debug code (っていうのか?)
> built-in ですよね。
超巨大なプログラムになると、
core が リミッタに引っかかり、
gdb 等のデバッガが使用できなくなるので、
皆さん色々苦労してます。
最後になりましたが、
片山さん、解答ありがとうございました。
s/\./,/
は、今後の課題とさせて頂きます（へへ）。
以上。
MAEDA Atusi
> しかし、
> ・原子力発電所の制御
> ・航空機の制御、
> ・自動車エンジンの制御
> 等で、ａｓｓｅｒｔを有効にして出荷する事が、
> 良い事なのか、
> 悪い事なのか、
> 私にはわかりません。
assert(あるいは類似のエラーチェック)に引っかかるバグがあった場合を考え
れば分かるのではないですか?
無ければ，何が起こるか分からない．バグの記録も残らない．
チェックが入れてあれば，少なくとも記録は(たとえばNVRAMに)とれるし，う
まくすればフェイルセイフ処理を試みることもできるでしょう．
高い信頼性の必要なシステムでは，「別々のチームに書かせた複数のモジュー
ルで同じ計算を行ない，結果を突き合わせてチェックする」なんていう話を聞
いたこともあります．
> ｃ８９仕様で、
> #if DEBUG
> #define SNAP printf
> #else
> #define SNAP
> #endif
> と、定義した場合、
#ifndef NDEBUG
#define SNAP(x) printf x
#else
#define SNAP(x)
#endif
SNAP(("%s:%d:...",__FILE__.__LINE__));
とか．C-FAQにもありますね(プリプロセッサの章の最後の方)．
マクロじゃなくて関数呼び出しにしとくのが大抵の場合は正解だと思いますが...
前田敦司
tabe
"MAEDA Atusi" <ma...@cc.tsukuba.ac.jp> wrote in message
news:m3u19bx...@maedapc.cc.tsukuba.ac.jp...
> > 等で、ａｓｓｅｒｔを有効にして出荷する事が、
> > 良い事なのか、
> > 悪い事なのか、
> > 私にはわかりません。
> assert(あるいは類似のエラーチェック)に引っかかるバグがあった場合を考え
> れば分かるのではないですか?
コンパイラ提供の、
assert() と、
単なるデバッグプリント文を明確に分けて考えてください。
assert() は、プログラムが即死します。
私が、わからないと言っているのは、
以下のコードでassert() を有効にして出荷して良いかどうかです。
switch(コイン) {
case 裏: break ;
case 表: break ;
default:
assert() ; // ここが、単なるprintf文や、log収集なら何の問題
も無し。
}
ちなみに、コインは結構簡単に、立ちます。
以上。
MAEDA Atusi
> > assert(あるいは類似のエラーチェック)に引っかかるバグがあった場合を考え
> > れば分かるのではないですか?
>
> コンパイラ提供の、
> assert() と、
> 単なるデバッグプリント文を明確に分けて考えてください。
＃むかっっ
元々SNAPという「単なるデバッグプリント」マクロの話だったのではないです
か．なんで偉そうに説教されなきゃならんのか．
> 私が、わからないと言っているのは、
> 以下のコードでassert() を有効にして出荷して良いかどうかです。
そうですか．それはあなたの説明不足ですね．
簡便なassertは便利な場合も多いですが，自ずと限界があります．
ケースバイケースとしか言いようがないでしょう．
> assert() ; // ここが、単なるprintf文や、log収集なら何の問題
> も無し。
assert(0)の意ですかね．
> ちなみに、コインは結構簡単に、立ちます。
なら，assert(0)とかabort()を入れるのは明らかに間違いですね．
当然，ここに制御が来る場合の処理を記述すべきでしょう．
前田敦司
Narita Takaoki
<m3ptjzw...@maedapc.cc.tsukuba.ac.jp>の記事において
ma...@cc.tsukuba.ac.jpさんは書きました。
> > ちなみに、コインは結構簡単に、立ちます。
>
> なら，assert(0)とかabort()を入れるのは明らかに間違いですね．
> 当然，ここに制御が来る場合の処理を記述すべきでしょう．
そうですね。
あの変な本にも、assert は絶対起こりえない状況を書けとかあったよう
な気がするんだけれど……なかったっけか？
当然、assert(0) で落ちると即、人が死ぬ可能性があるとかなら、
assert(0) にしないってのが筋ってもんだろうし。
私の説明も悪いのかもしれないけれど、assert を書く意味(心？^^;)を
一回の説明で理解してもらえたことってないなぁ。エレガントで明快な
説明って難しい……
--
成田 隆興 ＠ エー・アイ・ソフト株式会社 CS 品質推進課
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』
Shinji KONO
(そういえば、fj.comp.programming にWriting Solid Codeの
悪口を書いたときは反応0だった... で、その繰り返しなんだけど)
In article <bfr400$2hs$1...@news01.highway.ne.jp>, tak...@aisoft.co.jp (Narita Takaoki) writes
> あの変な本にも、assert は絶対起こりえない状況を書けとかあったよう
> な気がするんだけれど……なかったっけか？
そのサブルーチンでの前提条件を書けですね。早めにバグを見つける
手段として使うみたい。
> 当然、assert(0) で落ちると即、人が死ぬ可能性があるとかなら、
> assert(0) にしないってのが筋ってもんだろうし。
だから、当然、製品では落すわけですな。あの本(Writing Sold Code)
の変なところは、「製品になった後のエラーは、俺は知らん」という
考えなんだよな...
あと、エラーは悪いことだってのが前提としてあるみたい。
> 私の説明も悪いのかもしれないけれど、assert を書く意味(心？^^;)を
> 一回の説明で理解してもらえたことってないなぁ。エレガントで明快な
> 説明って難しい……
サブルーチンに前提条件があるとすれば、それを明示しろってのは
理解できます。しかし、それをチェックすると遅くなるってのは、
僕は、なんか変だと思う。コンパイラや実行時の工夫で、それは避
けられるはず。
オブジェクト指向とかコードの再利用、あるいは、プラグインなどが
導入された現在では、
処理を実行する前提条件は、必ず、チェックする
ってのが必須だと思う。なので、assert ってのは現状にあってな
いと思います。この手のコードは残るべきなのね。そして、
エラーチェックで失敗したときに、あと引き受ける
ことが必須だと思う。もちろん、絶対に復帰できないエラーっての
があるのは、そうだと思うんだけど、オブジェクトとかメモリプー
ルとかプロセスとか使うことによって結構避けられると思うんだけ
ど。
というわけで、僕の立場は、
エラー処理をしないことが前提のassertは、製品化しないような
プログラム(あるいは、マイクロソフトの売ったら勝ち、バグは
知らん方針)が前提であり、時代遅れであって、使ってはいけない
ものだ。
ってなもんです。
たぶん、数値計算とかだと「デバッグ時」と「計算時」がわかれている
から assert とか有効なのも知れないな。
Writing Sold Code には、もう一つ、
サブルーチンのエラー通知と値の返却を共用しない (つまりEOF==1やNaNみたいな
のを使わない)
ってものがあるんだけど、これもエラーを上位に通知しないことを
前提に書いていると思う。エラーを通知する手段としてreturn value
を使うのは僕は有効だと思う。実際、EOF は便利だし。
エラーを特別視することが間違っているんだろうな。プログラム理論
的にも⊥は便利だし。
Takashi SAKAMOTO
"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:3988646...@insigna.ie.u-ryukyu.ac.jp...
> そのサブルーチンでの前提条件を書けですね。早めにバグを見つける
> 手段として使うみたい。
私が得た印象では(もうかなり昔に読んだキリなのであやふやですが)、
処理が継続できないような間違った入力なら落とし、入力として想定
されてはいるが正しくはない場合にエラーとして返す…でした。
> サブルーチンに前提条件があるとすれば、それを明示しろってのは
> 理解できます。しかし、それをチェックすると遅くなるってのは、
> 僕は、なんか変だと思う。コンパイラや実行時の工夫で、それは避
> けられるはず。
>
> オブジェクト指向とかコードの再利用、あるいは、プラグインなどが
> 導入された現在では、
>
> 処理を実行する前提条件は、必ず、チェックする
>
> ってのが必須だと思う。なので、assert ってのは現状にあってな
> いと思います。
必ずチェックするは、同感ですが、
# オブジェクト指向でもエラーの返し方は…特に C++ か…
# 何の exception 投げるのかきちんと書いてくれてないと
# catch できなくて assert と変わらない気がしなくもない…。
# そう言えば、Java だと配列の範囲 check しなくても、exception で
# すむから安全だとかいう意見を itpro に見掛けた気がします。
# きちんと上で catch しているんだと信じたいですけど…
> この手のコードは残るべきなのね。そして、
>
> エラーチェックで失敗したときに、あと引き受ける
>
> ことが必須だと思う。もちろん、絶対に復帰できないエラーっての
> があるのは、そうだと思うんだけど、オブジェクトとかメモリプー
> ルとかプロセスとか使うことによって結構避けられると思うんだけ
> ど。
は、完全に実現しようとすると全て virtual machine の上で走らせて
最悪は virtual machine の再起動が必要になりませんか？
# virtual machine の使うデータは全て本体の database に登録して
# いつでも rollback できるようにするのかな。
> というわけで、僕の立場は、
>
> エラー処理をしないことが前提のassertは、製品化しないような
> プログラム(あるいは、マイクロソフトの売ったら勝ち、バグは
> 知らん方針)が前提であり、時代遅れであって、使ってはいけない
> ものだ。
>
> ってなもんです。
>
> たぶん、数値計算とかだと「デバッグ時」と「計算時」がわかれている
> から assert とか有効なのも知れないな。
エラー処理をしない、Microsoft がそう考えているかは知らないのですが、
「エラーを返しても処理できないのなら、エラーを返しても仕方ない」とも
Writing Solid Code には書かれていましたね。
# 「処理してくれないなら、abort してやる」みたいな話だったと記憶しています。
> Writing Sold Code には、もう一つ、
>
> サブルーチンのエラー通知と値の返却を共用しない (つまりEOF==1やNaNみた
いな
> のを使わない)
>
> ってものがあるんだけど、これもエラーを上位に通知しないことを
> 前提に書いていると思う。エラーを通知する手段としてreturn value
> を使うのは僕は有効だと思う。実際、EOF は便利だし。
これは返り値を「エラーを返す手段として使うなら、エラーかそうでないか
以外の値を含めない」「返り値に値を入れるなら、エラーは別経路で返す」と
言っているんじゃないかと思います。 > Writing Solid Code
あの本は library 作成者がその利用者である programmer を信じないという
本だと感じました。
だから、自分の設計する library が時と場合によって、
- エラーを返り値に含めたり、含めなかったり、
- エラーの判別方法が違ったり、
とかいった混乱を招くようなことをすると、programmerは必ずひっかかって
しまう、と。
それがゆえかは知らないのですが、Microsofot の COM は全て返り値の中
にはエラーかそうでないかの情報しか入らないです。
# そして、FAILED か SUCCEEDED かのマクロで失敗/成功の判別ができま
# す。
--
---
Takashi SAKAMOTO (PXG0...@nifty.ne.jp)
Shinji KONO
In article <bfslmv$r39$1...@news522.nifty.com>, "Takashi SAKAMOTO" <PXG0...@nifty.ne.jp> writes
> は、完全に実現しようとすると全て virtual machine の上で走らせて
> 最悪は virtual machine の再起動が必要になりませんか？
Unix では、そのVirutal machine はプロセスと呼ばれるんだけどね。
> # virtual machine の使うデータは全て本体の database に登録して
> # いつでも rollback できるようにするのかな。
本体とはなんぞや?
> あの本は library 作成者がその利用者である programmer を信じないという
> 本だと感じました。
その気分はわかる...
> それがゆえかは知らないのですが、Microsofot の COM は全て返り値の中
> にはエラーかそうでないかの情報しか入らないです。
> # そして、FAILED か SUCCEEDED かのマクロで失敗/成功の判別ができま
> # す。
それ、便利ですか?
どうも、Windows のアプリが落ちやすい原因がそのあたりにあるん
じゃないかなーっと...
Takashi SAKAMOTO
"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:3988651...@insigna.ie.u-ryukyu.ac.jp...
> Unix では、そのVirutal machine はプロセスと呼ばれるんだけどね。
Unix でも共有メモリをロックしっぱなしで process を落とすと危険だったりするこ
とはなかったでしょうか？ process では限界があると思うのですが。
# 全ての資源を仮想的なものにして、実在の資源とは一切切り離すところから
# やるといいのかな、と。
> 本体とはなんぞや?
すみません。こう、VMware を頭に思い浮かべて host os と guest os の host os
側を本体と勝手に呼んでいました。
> それ、便利ですか?
便利というか…個人で勝手にコードを書いている分には本人だけの責任だけど、
グループ開発するとなると、関数の引数や返り値、命名規則のルールを統一して
おいた方が良いですよね、という話なだけではないでしょうか… > Writing Solid
Code
# で、書き方の流儀が気に入らない、と往々にして論争になるわけですが…
# そういう場合には、グループでまた別の統一見解…統一規則を作ればいいんだ
# と思うのです。
> どうも、Windows のアプリが落ちやすい原因がそのあたりにあるん
> じゃないかなーっと...
…どうなのでしょう？ それよりも、そもそも COM が複雑で面倒ということの方が
大きいような気がします。
# Windows のアプリケーション全般が落ちやすいとなると、原因は COM とは違
# うところにありそうですが…。
# COM というと、Internet Explorer や Microsoft Office などが頭に浮かびます。
# あと、DirectX も COM になっていますね。
Takashi SAKAMOTO
"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote in message
news:3988651...@insigna.ie.u-ryukyu.ac.jp...
> Unix では、そのVirutal machine はプロセスと呼ばれるんだけどね。
Unix でも共有メモリをロックしっぱなしで process を落とすと危険だったりするこ
Shinji KONO
この場合はデバッグなんだから、デバッグ手法として使うってこと
なんだよな.... デバッグする段階と使う段階が別っていう考えが
そこにあるのは理解できます。が、なんか納得できない。
In article <bft900$c99$1...@news521.nifty.com>, "Takashi SAKAMOTO" <PXG0...@nifty.ne.jp> writes
> Unix でも共有メモリをロックしっぱなしで process を落とすと危険だったりするこ
> とはなかったでしょうか？ process では限界があると思うのですが。
flock/lockf とかだったらロックの主体はプロセスなので、その
プロセスが死ねば解放されます。
「プロセスの限界」ですか? 授業で記述問題で出そうかな。「Unix
のプロセスの限界を、エラー処理の観点から1000字程度で述べよ」
とか? うーん、でも自分でも、ちょっと簡単には書けないな。
プロセス自体は簡単でわかりやすいですよ。ややこしくなるのは、
thread と併用したときでしょう。
> # 全ての資源を仮想的なものにして、実在の資源とは一切切り離すところから
> # やるといいのかな、と。
ファイルとか通信ポートとかI/Oデバイスとかを実在の資源と切り
離すのは難しいと思う。Unix だとファイルディスクリプタみたい
な切口はありますが、少し足りないんですよね。
エラー処理は、
アプリあるいはライブラリ自体を階層的に作り、
その場、あるいは、上位階層で処理する
みたいに作らないとダメなのは当然なんだけど、なかなか
できないね。その階層の一つとしてプロセスがあるわけだけど。
最近だと、サンドボックスとかいう見たいですね。
> # Windows のアプリケーション全般が落ちやすいとなると、原因は COM とは違
> # うところにありそうですが…。
まぁ、もっともと、複雑なものになると、UnixだろうがWindows
だろうが関係ないって話もある。
Hideki Kato
In article <3988646...@insigna.ie.u-ryukyu.ac.jp>, Shinji KONO wrote:
>河野真治 @ 琉球大学情報工学です。
>あと、エラーは悪いことだってのが前提としてあるみたい。
悪いことと言うより（製品には？）有ってはならないこと，という考え方な
んでしょうかねぇ．人間の能力では実現不可能な．．．
>オブジェクト指向とかコードの再利用、あるいは、プラグインなどが
>導入された現在では、
>
> 処理を実行する前提条件は、必ず、チェックする
>
>ってのが必須だと思う。なので、assert ってのは現状にあってな
>いと思います。この手のコードは残るべきなのね。
N. Wirth がそう主張してましたね．
>そして、
>
> エラーチェックで失敗したときに、あと引き受ける
>
>ことが必須だと思う。もちろん、絶対に復帰できないエラーっての
>があるのは、そうだと思うんだけど、オブジェクトとかメモリプー
>ルとかプロセスとか使うことによって結構避けられると思うんだけ
>ど。
最初からそういうつもりで設計していればかなり拾えると思います．が，そ
れは大仕事です．例えば，コンパイラのエラーメッセージを適切に表示する
事を考えると，メインの仕事の数倍～数十倍の工数になるのでは？
>というわけで、僕の立場は、
>
> エラー処理をしないことが前提のassertは、製品化しないような
> プログラム(あるいは、マイクロソフトの売ったら勝ち、バグは
> 知らん方針)が前提であり、時代遅れであって、使ってはいけない
> ものだ。
>
>ってなもんです。
同感ですねぇ．PL 法をびしびし適用すべきなんでしょう．MS の OS のバグ
のせいで日々失われている損害は世界中で数百万ドル位はありそう．
>Writing Sold Code には、もう一つ、
>
> サブルーチンのエラー通知と値の返却を共用しない (つまりEOF==1やNaNみたいな
> のを使わない)
>
>ってものがあるんだけど、これもエラーを上位に通知しないことを
>前提に書いていると思う。エラーを通知する手段としてreturn value
>を使うのは僕は有効だと思う。実際、EOF は便利だし。
EOF は（例外の一種であって）エラーではないと思いますが？
>エラーを特別視することが間違っているんだろうな。プログラム理論
>的にも⊥は便利だし。
ですね．エラーは（起こるはずがないものではなく，起きるのが当たり前
の）例外の一種として扱うべきなんでしょう．
--
Hideki Kato <mailto:ka...@pop12.odn.ne.jp>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Hideki Kato
In article <3988654...@insigna.ie.u-ryukyu.ac.jp>, Shinji KONO wrote:
>河野真治 @ 琉球大学情報工学です。
>
>この場合はデバッグなんだから、デバッグ手法として使うってこと
>なんだよな.... デバッグする段階と使う段階が別っていう考えが
>そこにあるのは理解できます。が、なんか納得できない。
デバッグ段階と使う段階では，バグの検出までは共通だけど後の処理が異な
る（例えば，記録して止める ⇔ 回復を試みる，とか），ということなので
はないかしらむ．
>エラー処理は、
>
> アプリあるいはライブラリ自体を階層的に作り、
> その場、あるいは、上位階層で処理する
>
>みたいに作らないとダメなのは当然なんだけど、なかなか
>できないね。その階層の一つとしてプロセスがあるわけだけど。
Mac で VirtualPC を使ってた頃は Windows がコケても困らなかったから楽
でした（笑．
Hideo Sir MaNMOS Morishita
In article <3988654...@insigna.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 河野真治 @ 琉球大学情報工学です。
>
> この場合はデバッグなんだから、デバッグ手法として使うってこと
> なんだよな.... デバッグする段階と使う段階が別っていう考えが
> そこにあるのは理解できます。が、なんか納得できない。
最初の質問では製品の中にassertを入れるとかなんとか言っていたような。
> In article <bft900$c99$1...@news521.nifty.com>, "Takashi SAKAMOTO" <PXG0...@nifty.ne.jp> writes
> > Unix でも共有メモリをロックしっぱなしで process を落とすと危険だったりするこ
> > とはなかったでしょうか？ process では限界があると思うのですが。
>
> flock/lockf とかだったらロックの主体はプロセスなので、その
> プロセスが死ねば解放されます。
mmapで確保したメモリでプロセス共有のmutexとかつくると、osを再起動しよ
うがそのままでは復帰でしません。そのような場合、データの構造も壊れてし
まっていることが多く、データの再構築が必要となることもあるでしょう。一
部のデータはもう二度と復帰することができないかも知れません。
そういうプログラムでは制御が及ばないところでプロセスが死んでしまうと、
もうどうしようもありません。当然クリティカルなセクションではすべてのシ
グナルも制御し、最低限のrollbackをして再構築の時間を短くして終了するこ
とは当然でしょう。
＃assertなんて、考えも及ばない。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
Junn Ohta
ko...@ie.u-ryukyu.ac.jpさんは書きました。
> サブルーチンに前提条件があるとすれば、それを明示しろってのは
> 理解できます。しかし、それをチェックすると遅くなるってのは、
> 僕は、なんか変だと思う。コンパイラや実行時の工夫で、それは避
> けられるはず。
>
> オブジェクト指向とかコードの再利用、あるいは、プラグインなどが
> 導入された現在では、
>
> 処理を実行する前提条件は、必ず、チェックする
>
> ってのが必須だと思う。なので、assert ってのは現状にあってな
オープン関数でハンドルをもらってきて、メインの処理
ではそれぞれの関数にそのハンドルを渡すという造りの
ライブラリーって多いですよね。
で、たとえばDBMSとかだと、それぞれの関数が多段のレ
イヤーでできていて、上からもらったハンドルが延々下
のほうまでリレーで渡されることがよくあります。DBMS
の論理構造を知っているレイヤー、その下のISAMやハッ
シュなどのアクセスメソッドのレイヤー、さらにその下
のファイルアクセスモジュールのレイヤー、...といっ
たぐあい。
こんなとき、その記述子が正当なものであるかどうか、
たとえば記述子がNULLだったりしないこと、というのを
レイヤーごとに毎度毎度調べるのはむなしいものがあり
ますよね。こういう場合って、下のほうはassert()でい
いのでは?
もちろんレイヤーごとにその記述子に対してレイヤー独
自の情報を持たせていたりして、同じレイヤーで別の関
数がセットした情報などについてはチェックするのが当
然なんですが、それは別のレイヤーで重複してチェック
されるわけではないですから...。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp
Hideo Sir MaNMOS Morishita
私はdaemon屋さんが長いので、話が噛み合わないかも知れませんが。
In article <bg2ana$isv$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) writes:
>
> こんなとき、その記述子が正当なものであるかどうか、
> たとえば記述子がNULLだったりしないこと、というのを
> レイヤーごとに毎度毎度調べるのはむなしいものがあり
> ますよね。こういう場合って、下のほうはassert()でい
> いのでは?
うーん、それだと、使い物にならない場合は結構あります。とにかく、動き続
ける、どうしてもこれ以上進んだらやばいって場面でも、ある程度の深さまで
戻って、入ってきた処理はきっちりエラーとしてはじき飛ばす。ってことを行
わないと。
１時間止めたら億の損害とか言われますからね。
＃まあ、原子力と医療機器と交通関係には手を出さないようにしていますが…