GLib
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG長い事やってる人間だとこの辺は自作のものを持ってたりもするとは思いますが。
まだ自分が信頼するライブラリを作っていない／持っていない入門者から、LGPLに抵触しない範囲で
業務で使用しているという方、自作含め色んなライブラリを使ってきたという経験者の方含め...
GLibについて語るスレです。
http://www.gtk.org/
0002デフォルトの名無しさん
NGNGhttp://plaza20.mbn.or.jp/~shimaki/linux/article/gtk.html
どこに移転したか知っている人います？
0003デフォルトの名無しさん
NGNG0004デフォルトの名無しさん
NGNG自前でウィンドウからイベント処理まで作った記憶があるんですが･･･。
0005デフォルトの名無しさん
NGNG愕然としたんで使っていません。
愕然ってのは、mallocのラッパー関数。
メモリ取れなかったらプログラム強制終了、という仕様
だそうじゃありませんか。
そんなの、使えねーよ。
それで良い場面もあるんだろうけど、俺は困るね。
メモリ取れなかったら取れないなりに次の手を考えるような
プログラムしたい(という場合が殆どだ)もの。
というわけで、本当にただそれだけの理由で、
GLibとGLibに依存する無数のモノが
使えなくなりましたとさ。ちゃんちゃん。
0006デフォルトの名無しさん
NGNGmallocが死んだ状況でどのような手が打てるのか、興味があります。
0007デフォルトの名無しさん
NGNGg_malloc? ほんまかいな・・・
0008デフォルトの名無しさん
NGNGfree()はできないのか？
0010デフォルトの名無しさん
NGNGﾊｧ?malloc失敗してるのになにをfreeすんの？
そもそも何のためにmallocすんの？
メモリが必要だからでしょ？
その必要なメモリが確保できなくて、処理の続きができるの？
メモリ確保に失敗しても処理できるなら確保しなくても良いんじゃないの？
0011デフォルトの名無しさん
NGNGちゃうねん。
メモリ有る限りにおいてはコスト安いストラテジから
メモリ食わないけど普段は遅くて困るストラテジに
切り替えりゃいいんだよ。
0012デフォルトの名無しさん
NGNGGLibが使える環境でそれを動的に切り替えることにそれほど多きな需要が
あるとは到底思えないんだけど。とてもレアなケースなんじゃないの？
0013デフォルトの名無しさん
NGNG今持ってるデータをとりあえず吐き出したりとかいう処理を入れられないってこと？
0014デフォルトの名無しさん
NGNG0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNGFAQだろな。
glibc=gnu系(藁)libc
GLib=Gtkの足回りライブラリ
0017デフォルトの名無しさん
NGNGそもそも、メモリの確保に失敗するなんて事態があった場合、その
プロセス自体に致命的な障害が発生している可能性が高く、とりあえず
今持ってるデータを吐き出す、という処理も正しく動かないかも知れない。
さらに、悪あがきすることでシステムに深刻な影響を及ぼすという事は
考えられないかい？
ていうか、malloc失敗みたいなクリティカルなエラーが発生したときに
とりあえず途中でもデータ吐いておくなんていう処理をするシステムに
お目にかかったことがないんだけど、具体的にどんなのがあるよ？
0018デフォルトの名無しさん
NGNGOffice XP
0019257
NGNGとりあえず今作っているのでは
if (malloc失敗)
while(1)
で空回りさせておいてデバッガで追うようにはしています。
エラー処理を入れるのはある意味当然だと思いますよ。
0020デフォルトの名無しさん
NGNGおい？なんで「メモリ不足」という一番単純な状況を想定しないんだ？
モバイルunixなんかだとswapとらないことすらザラだぜ？
8Mとかのメモリ(swapが無いので論理的にも)でunix動かすなんて
いうんだから、メモリ不足なんてザラだろ？
じゃあGLibなんてやめろ、ってのは本末転倒だろう。
1:GLibのほかの機能は色々便利なのに使えないのが妥当なの？
2:GtkやGNOMEをモバイルに持ちこもうとしてる連中もいるし。
(式神もそうじゃなかったか?)
>今持ってるデータを吐き出す、という処理も正しく動かないかも知れない
正しく動かなかったらどんな実害が生じるか、を
考えるべきですね。
そういう場合だけ、書きこみ先を別ファイルにすれば
いいんじゃないの？(あ、openできないという話か？
でも以前のファイルはcloseできるだろし)
そうすりゃ、最悪駄目でも元ファイルは壊さない。
ジャーナリングやバージョン管理と似た考え、か？(^^;;;;
0021デフォルトの名無しさん
NGNG生mallocじゃなくboehmGC使いたいと思ったんですが、
華々しいHackをせずとも差し替え可能なように
GLibは出来ていますか？
0023デフォルトの名無しさん
NGNG>ハァ?malloc失敗してるのになにをfreeすんの？
まず念のため言っておくと、
malloc「が」壊れるわけはないよな。
新しい領域が取れなくなってるだけ。
それこそ不足とかかもだし。
なにかをぶっ壊して致命的な状況だとは限らないね。
>その必要なメモリが確保できなくて、処理の続きができるの？
なんで、今やろうとしてたのと「同じ」処理を
再開しないとならない、と決め付けるんだ？
たとえば「できませんでしたごめんなさいと謝る」
という処理でもいいわけだ。
少なくとも何も言わずにいきなり全滅するよりは「いい」だろ？
プロセス全体で1つの仕事をする、なんて考えるなよな。
場面ごとに仕事が変わる。
GLib→Gtk→GnomeなGUIの世界だと尚更そうなる。
だから、今やるべき第一候補の仕事が出来なければ
第二候補の仕事に移るべき。常に第二候補が存在しないとは
限らないだろ？上記のように謝るとかさ。
「謝る」なんて書いたら感性が曇って理性的に理解できなくなる(藁)人
のために書くと、例外処理って奴だな。
正常に動いたときとそうでないときでやることを変えるって奴。
そりゃ、今まさにしようとしてた仕事の当事者Objectは、死ぬしかない運命かも知れない。
が、他のObject全部を巻き添えにするのは、常に妥当といえるか？
それこそプロセス保護の概念と似たようなものだ。隣のObjectを無闇に壊すな。
0024デフォルトの名無しさん
NGNG長文ご苦労 sage
0025デフォルトの名無しさん
NGNGa) 先にヒープ上に適当な予備用のメモリを確保しておく
b) メモリのアロケートに失敗したときは(MacOS では失敗したときに呼ばれるフックを
定義できる)、予備用のメモリを開放し(これで本来の処理がある程度続けられる)、
ユーザーにメモリ不足について伝え、ドキュメントの保存等を促す
てな風にしてたけど。これは公式プログラミング本、"Inside Macintosh" でも推奨の方法。
0026デフォルトの名無しさん
NGNGMacみたいな狂った処理系の話こそレアケースだ。
0027デフォルトの名無しさん
NGNG落ちちまう馬鹿OSの上で落ちないような小細工をするってのと
落ちずにすむまともなOSの上で落ちちまうような小細工をする
ってのは、まるで一緒にはならぬ話だと思うが。
馬鹿Mac(の上)ですらこの程度のことは出来るってのに、という話だろ。
0028デフォルトの名無しさん
NGNGファイルハンドルだって予備に３，４個開いておけばいいじゃん。
0029デフォルトの名無しさん
NGNGWindows98も相当バカだと思うんですが、ｍａｃというのは
これよりさらにひどかったのですか？
それは、商品として売ってはいけないレベルですよ！
0030デフォルトの名無しさん
NGNGwinでいえば3.xより劣ると言っても良い面が多々ある。
なんで「アプリに割り当てるメモリ」なんてものを
(アプリごとに)設定する必要があるんだか。
必要なら必要な分だけallocしろよ。
MacOSにゃ素直なallocみたいなものも無かったらしい。
フロッピーベースの時代のOS
(メモリ不足を極限まで耐え忍ぶために
色々小賢しいことをしてたらしい)を
基本アーキテクチャ変えずに今までやっていけば、
そりゃ無理あるわな。
勿論良い面もあったんだけどさ。
0031デフォルトの名無しさん
NGNG貴重な情報ありがとうございます。
マックというと＝ｉ−ｍａｃみたいにデザインに優れ、
デザイナーも芸能人も映画俳優もマックばっかり使う、
素晴らしいマシン。
という捏造されたイメージしかなくて恥ずかしいです。
0032デフォルトの名無しさん
NGNGところがな、MacOS(X未満)はアプリに割り当てられるメモリがヒープもスタックも
リニアに一緒くたになってて、しかもヒープとスタックの境目を検出する手段が
ないのよ。
予備のメモリを取っておくのは、スタック破壊を予防することを期待してる面も
あるの。なにしろこれ壊れるとシステムごと落ちるから。
0033デフォルトの名無しさん
NGNG>>31だって分かってバカにしているんだろうから。
0034デフォルトの名無しさん
NGNGmalloc が失敗したらナニすんだゴラァ、って方の話を進めるための
叩き台というかネタフリなんだから。unix だとファイルハンドルと
ポート番号とかその辺のリソースについても考えないとね。
0035デフォルトの名無しさん
NGNGかかってるらしい。
http://www-6.ibm.com/jp/developerworks/linux/000811/j_glib.html
>メモリーの割り振り
>最初に、最も基本的なコンポーネントである、メモリーの割り振りについ
>て取り上げます。標準の malloc と free も悪くありませんが、完全では
>ありません。たとえば NULL を渡すと、free はクラッシュし、malloc は
>NULL を戻します。戻り値を検査することを怠ると、アプリケーションが
>予期しない振る舞いをすることがあります。 GLib には、それに対応す
>る関数として g_malloc と g_free が定義されています。 g_malloc は、新
>しいメモリーへのポインターを戻すことが保証されています。メモリーを
>これ以上割り振ることができなくなると、プログラムは打ち切られます。
>これは、後で NULL ポインターを扱えなくなって segfault を受け取るよ
>りは望ましいことです。 g_free 関数には NULL を渡すことができますが、
>その場合、この関数は何もしません。これは、解放する必要のあるポイ
>ンターを多数持つオブジェクトがある場合に、クリーナー関数の役割を
>果たします。
0036デフォルトの名無しさん
NGNGhttp://www.ainet.or.jp/~inoue/gnome/tech/glib.html
>g_malloc()内部で、malloc()が失敗した場合にg_error()で実行をストップ
>するので、g_malloc()の戻り値のエラーチェックを書く必要がありません。
>少しコーディング量が減らせます。逆に言うと、メモリ割り当てに失敗し
>てもストップせずに頑張りたいプログラムの場合、g_malloc()を使わない
>か、あるいはg_error()にハンドラ関数を定義するなどの工夫をする必要
>があります。 (Glib開発版には、g_try_malloc()がありますが、この用途?)
00376
NGNGあれれ？最近のANSIかなんかでは、free(NULL)は
何もせずに帰るのが保証されてたんじゃなかった？
0038デフォルトの名無しさん
NGNG最近の富豪(ブルジョワ)なプログラマは、だろうね。
>>36
まさかGLibの中のほかの個所でg_malloc()が
使われてないわけじゃないよねえ？
となると、Callbackなりフラグ(藁)なりで
g_mallocの凶行を防ぐ手段は、ほしいよ。
まぁいずれにせよ、例外という便利なものが使えない生C世界での
苦肉の策だな。そのまま進むか丸ごと落とすか二者択一しかない。
例外なら好きなレベルまで落とすことが出来るわけで。
0039デフォルトの名無しさん
NGNG関数でラップすれば問題は起らないだろ。
問題の起る環境毎に最適な対処処理を分けて書く。
void *xmalloc(size_t size) {
void *t;
assert(size > 0);/*size=0の呼出しは禁止する*/
t = (void *)malloc(size);
assert(t); /*mallocは失敗しない事を前提にする*/
return t;
}
void xfree(void *t) {
assert(t); /*NULL呼出しは禁止する*/
free(t);
}
0040デフォルトの名無しさん
NGNGされてる。手元に規格書がないので、プログラミング言語Cからの抜粋。
void free(void *p)
free は p が指すスペースを開放する。ただし p が NULL のときには何も
起きない。
私は free(NULL) はよく使うけど。
0041デフォルトの名無しさん
NGNG>となると、Callbackなりフラグ(藁)なりで
>g_mallocの凶行を防ぐ手段は、ほしいよ。
「g_error()にハンドラ関数を定義」というのがそれじゃないかと思ったんだ
けど違うの?
■ このスレッドは過去ログ倉庫に格納されています