fdpl_memo0007
の編集
https://k.osask.jp/klog/?fdpl_memo0007
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2012_0001
2013_0001
2013_0002
2013_0003
2014_0001
2015_0001
2016_07
2016_08
2016_09
2016_10
2016_11
2017_01
2017_02
2017_03
2017_04
2017_05
2018_01
2019_01
BracketName
FormattingRules
FrontPage
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KH_SARC_00
KH_dha8
MenuBar
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
VC_install
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
fdpl_memo0001
fdpl_memo0002
fdpl_memo0003
fdpl_memo0004
fdpl_memo0005
fdpl_memo0006
fdpl_memo0007
fdpl_memo0008
fdpl_memo0009
fdpl_memo0010
gg02_0004
gg02_0005
gg02_0006
gg02_0007
gg02_0008
gg02_0009
https
impressions
memo0001
memo0002
oisix01
osaskology
osaskology0
osecpu_0001
osecpu_0002
p20200229a
p20200303a
p20200310a
p20200321a
p20200401a
p20200730a
p20201230a
p20220628a
p20220701a
populars
prog_0001
prog_0002
prog_0003
prog_0004
prog_0005
* KH-FDPL に関するメモ-0007 -(by [[K]], 2015.02.16) ** KH-FDPLの特徴(3) - オブジェクト(変数)の寿命管理 -(3-1) C++ではnewでオブジェクトを作ってdeleteで破棄していました。また自動変数(スタック上にとられる変数)はスコープから抜けるときに自動でデストラクタが呼び出されていました。 --この自動変数の挙動は便利で分かりやすくて深刻なメモリリークバグも起こりにくいと思いますが、自分でnewして作ったオブジェクトについてはdeleteを呼び忘れたりしてメモリリークバグの大きな原因となっています。 -(3-2) JavaではGC(ガーベージコレクション)を採用し、プログラマがdeleteしないでもいいようにしました。 --これは一見すると非常にかっこいいのですが、実際は処理系が未使用のオブジェクトをうまく検出できずにメモリリークしてしまったり(特に循環参照などが起こるとリークしやすい)、full-GCが始まるとプログラムがしばらくの間とまってしまう問題があります。 --GCは多くの場合ではプログラマを寿命管理から解放してくれます。しかしそのせいでこれに配慮しないことに慣れてしまい、リークやfull-GCに悩まされ始めた時にどうしていいかわからなくて途方に暮れることになります。これはあまり教育的な仕様とは言えないでしょう。 -(3-3) これらに対する比較的新しい方法として、autorelease方式があります。iOSのObjective-Cで使われています。 --これはとても良い方法だと思いました。KH-FDPLでも最初はこの方法をそのまま取り入れようと思っていたくらいです。 --ただautoreleaseしない場合に、retainやreleaseで参照カウンタを管理しなければいけません。その部分の難易度が従来と大差ないと思いました。ここで間違えればやはりメモリリークしてしまいます。 -(3-4) KH-FDPLの方式。 --KH-FDPLは参照カウンタを持ちません。結局こういうものをプログラマに管理させていると、永久にメモリリーク問題はなくならないと思うからです。 --短期間で作って壊すようなオブジェクトは、まさにautoreleaseと同じ方法で管理します。次回の回収時に回収されるプールがあるので、そこに登録するわけです。 --そしてそれより長く生き残るオブジェクトに関しては、どのプールに所属するかを「new時に」指定します。どんなプログラムも、最低一つのプールを持っていますし、関数呼び出しをすればそのたびにプールが作られます。それらの中のどのプールに所属するのかをnew時に指定すればいいのです。 --これにより、そのプールが回収されるときに必ずオブジェクトは回収されます。リークしません。 --もし寿命を変更したくなれば、あとから所属するプールを変更すればいいです。それで問題ありません。 --プールを指定するなんて言うとややこしく聞こえますが、ファイルを作るときに所属パスを指定するのと同じくらいの感覚です。何も指定しなければ、次回回収プールがデフォルトで選ばれます(autorelease相当)。関数の戻り値用のオブジェクトは、次々回回収プールがデフォルトになります。 --そもそもオブジェクトを作るときが、もっともオブジェクトの寿命について考えているときでもあるのです。オブジェクトを作るときは、そのオブジェクトを何のために作るのかわかっていますし(目的)、だからいついらなくなるのかもわかっているのです。 -(3-5) KH-FDPLはオブジェクトが基本的に永続性なので、メモリリークは非常に深刻です。 --だからこんなにリークさせない仕組みにこだわっているのです。 --KH-FDPLでリークを起こしてしまったら、それは再起動後にも残るので、放置していると永久に残ります。他の言語環境ならリークしても再起動すれば済みますが、KH-FDPLではそうは行かないわけです。まあ自分でせっせとリークしたオブジェクトを特定して消していけばいいといえばそれまでですが、それよりはリークを起こさない仕組みを考えるほうが建設的だと思います。 * こめんと欄 -いまのobjective-cはarcというコンパイラが参寿命管理する仕組みがあるのでobjective-cの世界の中だけなら自分で参照カウンタ管理しなくても循環参照以外でリークすることはほとんどないです -- ''neri'' SIZE(10){2015-02-17 (火) 10:29:33} -おおすごい!そう、arcっていうのがあるのはうわさに聞いていたけど詳細は知りませんでした。循環参照以外は問題なしっていうのは、JavaのGCと同等の条件ですが、でもObjective-Cだとfull-GCとかで止まったりはしないので、圧倒的に優秀ですね! -- ''K'' SIZE(10){2015-02-17 (火) 14:26:24} #comment
タイムスタンプを変更しない
* KH-FDPL に関するメモ-0007 -(by [[K]], 2015.02.16) ** KH-FDPLの特徴(3) - オブジェクト(変数)の寿命管理 -(3-1) C++ではnewでオブジェクトを作ってdeleteで破棄していました。また自動変数(スタック上にとられる変数)はスコープから抜けるときに自動でデストラクタが呼び出されていました。 --この自動変数の挙動は便利で分かりやすくて深刻なメモリリークバグも起こりにくいと思いますが、自分でnewして作ったオブジェクトについてはdeleteを呼び忘れたりしてメモリリークバグの大きな原因となっています。 -(3-2) JavaではGC(ガーベージコレクション)を採用し、プログラマがdeleteしないでもいいようにしました。 --これは一見すると非常にかっこいいのですが、実際は処理系が未使用のオブジェクトをうまく検出できずにメモリリークしてしまったり(特に循環参照などが起こるとリークしやすい)、full-GCが始まるとプログラムがしばらくの間とまってしまう問題があります。 --GCは多くの場合ではプログラマを寿命管理から解放してくれます。しかしそのせいでこれに配慮しないことに慣れてしまい、リークやfull-GCに悩まされ始めた時にどうしていいかわからなくて途方に暮れることになります。これはあまり教育的な仕様とは言えないでしょう。 -(3-3) これらに対する比較的新しい方法として、autorelease方式があります。iOSのObjective-Cで使われています。 --これはとても良い方法だと思いました。KH-FDPLでも最初はこの方法をそのまま取り入れようと思っていたくらいです。 --ただautoreleaseしない場合に、retainやreleaseで参照カウンタを管理しなければいけません。その部分の難易度が従来と大差ないと思いました。ここで間違えればやはりメモリリークしてしまいます。 -(3-4) KH-FDPLの方式。 --KH-FDPLは参照カウンタを持ちません。結局こういうものをプログラマに管理させていると、永久にメモリリーク問題はなくならないと思うからです。 --短期間で作って壊すようなオブジェクトは、まさにautoreleaseと同じ方法で管理します。次回の回収時に回収されるプールがあるので、そこに登録するわけです。 --そしてそれより長く生き残るオブジェクトに関しては、どのプールに所属するかを「new時に」指定します。どんなプログラムも、最低一つのプールを持っていますし、関数呼び出しをすればそのたびにプールが作られます。それらの中のどのプールに所属するのかをnew時に指定すればいいのです。 --これにより、そのプールが回収されるときに必ずオブジェクトは回収されます。リークしません。 --もし寿命を変更したくなれば、あとから所属するプールを変更すればいいです。それで問題ありません。 --プールを指定するなんて言うとややこしく聞こえますが、ファイルを作るときに所属パスを指定するのと同じくらいの感覚です。何も指定しなければ、次回回収プールがデフォルトで選ばれます(autorelease相当)。関数の戻り値用のオブジェクトは、次々回回収プールがデフォルトになります。 --そもそもオブジェクトを作るときが、もっともオブジェクトの寿命について考えているときでもあるのです。オブジェクトを作るときは、そのオブジェクトを何のために作るのかわかっていますし(目的)、だからいついらなくなるのかもわかっているのです。 -(3-5) KH-FDPLはオブジェクトが基本的に永続性なので、メモリリークは非常に深刻です。 --だからこんなにリークさせない仕組みにこだわっているのです。 --KH-FDPLでリークを起こしてしまったら、それは再起動後にも残るので、放置していると永久に残ります。他の言語環境ならリークしても再起動すれば済みますが、KH-FDPLではそうは行かないわけです。まあ自分でせっせとリークしたオブジェクトを特定して消していけばいいといえばそれまでですが、それよりはリークを起こさない仕組みを考えるほうが建設的だと思います。 * こめんと欄 -いまのobjective-cはarcというコンパイラが参寿命管理する仕組みがあるのでobjective-cの世界の中だけなら自分で参照カウンタ管理しなくても循環参照以外でリークすることはほとんどないです -- ''neri'' SIZE(10){2015-02-17 (火) 10:29:33} -おおすごい!そう、arcっていうのがあるのはうわさに聞いていたけど詳細は知りませんでした。循環参照以外は問題なしっていうのは、JavaのGCと同等の条件ですが、でもObjective-Cだとfull-GCとかで止まったりはしないので、圧倒的に優秀ですね! -- ''K'' SIZE(10){2015-02-17 (火) 14:26:24} #comment
テキスト整形のルールを表示する