fdpl_memo0004
の編集
https://k.osask.jp/klog/?fdpl_memo0004
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
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 に関するメモ-0004 -(by [[K]], 2015.02.09) ** また整理(2015.02.09) -いろいろ試行錯誤しています。基本的な目的(=やりたいこと)に変化はないのですが、それをどうにかしてシンプルに実現したいので、設計をがんばっています。 -(1) 高度なアクセス権管理は廃止になり、制限アクセスとしては単純なリードオンリーのみをサポートします。 --リードオンリーなオブジェクトに対しては、読み出ししかできません。書き足しも削除も名前(変数名、メンバ名)の変更も一切受け付けません。すべてエラーにします。 --さらにリードオンリーオブジェクトに対するリンク(つまり他のオブジェクトのメンバにすること)も認めません。これはライトもできるオブジェクトの中にリードオンリーなオブジェクトをリンクさせることで、管理が複雑になる事態を避けるためです。 --もちろん、リードオンリーなオブジェクトをフルコピーすることはできますので、フルコピーした上でそのコピーへのリンクを張ることはできます。しかしこのコピーをどれだけ改変しようとも、オリジナルは影響を受けません。 -(2) KH-FDPLでは全てのオブジェクトがメモリ上のファイルシステムみたいなものの一部として管理されます。 --普通にmallocすると当然ながら名前を指定できないのですが、内部ではちゃんと適当な名前が割り当てられます(その名前をあとから取得することもできます)。どこのディレクトリにオブジェクトを置くかということも含めて、設定しておくことになります。 --たいていは(=デフォルトでは)スタックという名前のフォルダにオブジェクト類は置かれることになります(フォルダ名はスタックじゃないかもしれないけど)。関数から出るときに、このフォルダをフォルダごと消してしまえば、メモリリークする心配はありません。つまりいわゆるスタック変数はここに置くわけです。 --関数を呼び出すたびにスタックフォルダが作られていくイメージです。 --関数の戻り値などは、スタックフォルダに作ってしまうとうまくいかないので、戻り値を置くためのフォルダを関数に渡すことになります。たいていの場合、このフォルダは呼び出し側のスタックフォルダです。 -(3) setter, getter関数をより自然に書けます。 --値をセットするときはsetter関数を、値を取得するときはgetter関数を使う、みたいなのがオブジェクト指向言語ではよくありますが、KH-FDPLでは「代入しようとしたときに呼んでほしい関数を登録しておく・値を参照しようとしたときに呼んでほしい関数を登録しておく」ということができるので、c = a + b; と書くだけでも、実はaやbのgetter関数が呼ばれてcのsetter関数が呼ばれる、ということができます。 --ちなみにただの変数オブジェクトに対しても添え字の付与や関数型呼び出しをすることができます。 --つまり a = 3; に対して、 a()やa(4)やa[5]などができます。いずれも値は3を返します(引数や添え字は無視される)。 -(4) copy-on-writeのサポートがあります。 --ここでいうcopy-on-writeのサポートというのは、つまり内容がよく似た配列やオブジェクトがあって、でも一部だけ違うみたいな場合に、消費メモリが単純に二倍にならずに済む、というものです。 --内容が完全に同一なら、消費メモリはほとんど増えずに済みます。 * こめんと欄 #comment
タイムスタンプを変更しない
* KH-FDPL に関するメモ-0004 -(by [[K]], 2015.02.09) ** また整理(2015.02.09) -いろいろ試行錯誤しています。基本的な目的(=やりたいこと)に変化はないのですが、それをどうにかしてシンプルに実現したいので、設計をがんばっています。 -(1) 高度なアクセス権管理は廃止になり、制限アクセスとしては単純なリードオンリーのみをサポートします。 --リードオンリーなオブジェクトに対しては、読み出ししかできません。書き足しも削除も名前(変数名、メンバ名)の変更も一切受け付けません。すべてエラーにします。 --さらにリードオンリーオブジェクトに対するリンク(つまり他のオブジェクトのメンバにすること)も認めません。これはライトもできるオブジェクトの中にリードオンリーなオブジェクトをリンクさせることで、管理が複雑になる事態を避けるためです。 --もちろん、リードオンリーなオブジェクトをフルコピーすることはできますので、フルコピーした上でそのコピーへのリンクを張ることはできます。しかしこのコピーをどれだけ改変しようとも、オリジナルは影響を受けません。 -(2) KH-FDPLでは全てのオブジェクトがメモリ上のファイルシステムみたいなものの一部として管理されます。 --普通にmallocすると当然ながら名前を指定できないのですが、内部ではちゃんと適当な名前が割り当てられます(その名前をあとから取得することもできます)。どこのディレクトリにオブジェクトを置くかということも含めて、設定しておくことになります。 --たいていは(=デフォルトでは)スタックという名前のフォルダにオブジェクト類は置かれることになります(フォルダ名はスタックじゃないかもしれないけど)。関数から出るときに、このフォルダをフォルダごと消してしまえば、メモリリークする心配はありません。つまりいわゆるスタック変数はここに置くわけです。 --関数を呼び出すたびにスタックフォルダが作られていくイメージです。 --関数の戻り値などは、スタックフォルダに作ってしまうとうまくいかないので、戻り値を置くためのフォルダを関数に渡すことになります。たいていの場合、このフォルダは呼び出し側のスタックフォルダです。 -(3) setter, getter関数をより自然に書けます。 --値をセットするときはsetter関数を、値を取得するときはgetter関数を使う、みたいなのがオブジェクト指向言語ではよくありますが、KH-FDPLでは「代入しようとしたときに呼んでほしい関数を登録しておく・値を参照しようとしたときに呼んでほしい関数を登録しておく」ということができるので、c = a + b; と書くだけでも、実はaやbのgetter関数が呼ばれてcのsetter関数が呼ばれる、ということができます。 --ちなみにただの変数オブジェクトに対しても添え字の付与や関数型呼び出しをすることができます。 --つまり a = 3; に対して、 a()やa(4)やa[5]などができます。いずれも値は3を返します(引数や添え字は無視される)。 -(4) copy-on-writeのサポートがあります。 --ここでいうcopy-on-writeのサポートというのは、つまり内容がよく似た配列やオブジェクトがあって、でも一部だけ違うみたいな場合に、消費メモリが単純に二倍にならずに済む、というものです。 --内容が完全に同一なら、消費メモリはほとんど増えずに済みます。 * こめんと欄 #comment
テキスト整形のルールを表示する