note0002
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
開始行:
* KH-FDPLのノート0002
-(by [[K]], 2015.03.17)
** (1) 一般的なオブジェクトの寿命の管理モデル
-C++ではnewでオブジェクトを作ってdeleteで破棄していました...
--この自動変数の挙動は便利で分かりやすくて深刻なメモリリ...
-JavaではGC（ガーベージコレクション）を採用し、プログラマ...
--これは一見すると非常にかっこいいのですが、実際は処理系...
--GCは多くの場合ではプログラマを寿命管理から解放してくれ...
-これらに対する比較的新しい方法として、autorelease方式が...
--これはとても良い方法だと思いました。KH-FDPLでも最初はこ...
--ただautoreleaseしない場合に、retainやreleaseで参照カウ...
--最近のarcの仕組みを使うと、retainやreleaseを意識しなく...
** (2) KH-FDPLのオブジェクトの寿命の管理モデル
-KH-FDPLは参照カウンタを持ちません。結局こういうものをプ...
-短期間で作って壊すようなオブジェクトは、まさにautoreleas...
-そしてそれより長く生き残るオブジェクトに関しては、どのプ...
--これにより、そのプールが回収されるときに必ずオブジェク...
--もし寿命を変更したくなれば、あとから所属するプールを変...
-プールを指定するなんて言うとややこしく聞こえますが、ファ...
-そもそもオブジェクトを作るときが、もっともオブジェクトの...
-KH-FDPLはオブジェクトが基本的に永続性なので、メモリリー...
だからこんなにリークさせない仕組みにこだわっているのです。
-KH-FDPLでリークを起こしてしまったら、それは再起動後にも...
** (3) じゃあ他の管理アルゴリズムは使えないのか？
-KH-FDPLは多様な言語を受け入れたいと思っています。GCが好...
-まずは簡単なnew-deleteモデルから行きましょう。このモデル...
-GCの場合も同様です。GCスレッドは、プールの中のすべてのオ...
** (4) KH-FDPLの方法で本当にうまくいくのか？ [ここはかな...
-new-deleteモデルは、「使わなくなったらdeleteしてください...
-KH-FDPLでは、関数を呼ぶ直前に「スタックフレーム」という...
-関数はローカル変数を使います。そうするとそれらのローカル...
-関数から抜けると、スタックフレームは削除されます（もしか...
-関数が関数を呼び出した場合、スタックフレームの中にスタッ...
-ローカル変数についてはこれで良いとして、それではそれ以外...
-この場合、そのオブジェクトを「どこに作るのか」を呼び出し...
-しかし、そもそもsubという関数が呼び出し元であるmainのス...
-ここまでをまとめます。
main()
{
sub0(@stack);
...
}
sub0(pool)
{
sub1(pool);
...
}
sub1(pool)
{
pool内にオブジェクトを作る命令;
...
}
-こんな感じになります。sub1が実際にオブジェクトを作ってい...
-でももっとカッコよくやるならこうだと思います。
main()
{
work = sub0();
...
}
sub0()
{
returnValue = sub1();
...
return returnValue;
}
sub1()
{
obj.foo = ...;
obj.bar = ...;
...
return obj;
}
-結果的に、sub1が作ったオブジェクトはmainのworkとして残る...
-より詳細な流れ：
--(a) システムはmainを呼び出すにあたって@stackというフォ...
--(b) main()はさらに@stackというフォルダを作ってそこをカ...
--(c) sub0()はさらに@stackというフォルダを作ってそこをカ...
--(d) sub1()はカレントディレクトリにobjというフォルダを作...
--(e) sub1()でのreturn命令により、objは@retValにリネーム...
--(f) sub0()ではフォルダの階層を元に戻す。その上で@stack....
---どうせ@stackは次の関数呼び出しまでには消える運命なので...
--(g) sub0()でのreturn命令により、returnValueは@retValに...
--(h) main()ではフォルダの階層を元に戻す。その上で@stack....
* こめんと欄
#comment
終了行:
* KH-FDPLのノート0002
-(by [[K]], 2015.03.17)
** (1) 一般的なオブジェクトの寿命の管理モデル
-C++ではnewでオブジェクトを作ってdeleteで破棄していました...
--この自動変数の挙動は便利で分かりやすくて深刻なメモリリ...
-JavaではGC（ガーベージコレクション）を採用し、プログラマ...
--これは一見すると非常にかっこいいのですが、実際は処理系...
--GCは多くの場合ではプログラマを寿命管理から解放してくれ...
-これらに対する比較的新しい方法として、autorelease方式が...
--これはとても良い方法だと思いました。KH-FDPLでも最初はこ...
--ただautoreleaseしない場合に、retainやreleaseで参照カウ...
--最近のarcの仕組みを使うと、retainやreleaseを意識しなく...
** (2) KH-FDPLのオブジェクトの寿命の管理モデル
-KH-FDPLは参照カウンタを持ちません。結局こういうものをプ...
-短期間で作って壊すようなオブジェクトは、まさにautoreleas...
-そしてそれより長く生き残るオブジェクトに関しては、どのプ...
--これにより、そのプールが回収されるときに必ずオブジェク...
--もし寿命を変更したくなれば、あとから所属するプールを変...
-プールを指定するなんて言うとややこしく聞こえますが、ファ...
-そもそもオブジェクトを作るときが、もっともオブジェクトの...
-KH-FDPLはオブジェクトが基本的に永続性なので、メモリリー...
だからこんなにリークさせない仕組みにこだわっているのです。
-KH-FDPLでリークを起こしてしまったら、それは再起動後にも...
** (3) じゃあ他の管理アルゴリズムは使えないのか？
-KH-FDPLは多様な言語を受け入れたいと思っています。GCが好...
-まずは簡単なnew-deleteモデルから行きましょう。このモデル...
-GCの場合も同様です。GCスレッドは、プールの中のすべてのオ...
** (4) KH-FDPLの方法で本当にうまくいくのか？ [ここはかな...
-new-deleteモデルは、「使わなくなったらdeleteしてください...
-KH-FDPLでは、関数を呼ぶ直前に「スタックフレーム」という...
-関数はローカル変数を使います。そうするとそれらのローカル...
-関数から抜けると、スタックフレームは削除されます（もしか...
-関数が関数を呼び出した場合、スタックフレームの中にスタッ...
-ローカル変数についてはこれで良いとして、それではそれ以外...
-この場合、そのオブジェクトを「どこに作るのか」を呼び出し...
-しかし、そもそもsubという関数が呼び出し元であるmainのス...
-ここまでをまとめます。
main()
{
sub0(@stack);
...
}
sub0(pool)
{
sub1(pool);
...
}
sub1(pool)
{
pool内にオブジェクトを作る命令;
...
}
-こんな感じになります。sub1が実際にオブジェクトを作ってい...
-でももっとカッコよくやるならこうだと思います。
main()
{
work = sub0();
...
}
sub0()
{
returnValue = sub1();
...
return returnValue;
}
sub1()
{
obj.foo = ...;
obj.bar = ...;
...
return obj;
}
-結果的に、sub1が作ったオブジェクトはmainのworkとして残る...
-より詳細な流れ：
--(a) システムはmainを呼び出すにあたって@stackというフォ...
--(b) main()はさらに@stackというフォルダを作ってそこをカ...
--(c) sub0()はさらに@stackというフォルダを作ってそこをカ...
--(d) sub1()はカレントディレクトリにobjというフォルダを作...
--(e) sub1()でのreturn命令により、objは@retValにリネーム...
--(f) sub0()ではフォルダの階層を元に戻す。その上で@stack....
---どうせ@stackは次の関数呼び出しまでには消える運命なので...
--(g) sub0()でのreturn命令により、returnValueは@retValに...
--(h) main()ではフォルダの階層を元に戻す。その上で@stack....
* こめんと欄
#comment
ページ名:
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
