eoml0002
の編集
https://khfdpl.osask.jp:443/wiki/?eoml0002
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2016_10
2016_11
2016_12
BracketName
Essen
Essen0
Essen1
Essen2
Essen3
Essen4
EssenMemo0001
EssenMemo0002
EssenMemo0003
EssenMemo0004
EssenMemo0005
EssenMemo0006
EssenMemo0007
EssenMemo0008
EssenMemo0009
EssenMemo0010
EssenMemo0011
EssenR2
EssenR2_ess03f
EssenR2_ess03h
EssenR2_ess03i
EssenR2_ideas
EssenR2_jit00
EssenR2_jit01
FormattingRules
FrontPage
Help
IP
InterWiki
InterWikiName
InterWikiSandBox
K
KHPC
KHPC_v000doc01
KHPC_v001doc01
KHPC_v002doc01
KHPC_v003doc01
MenuBar
OSC
OSC20181027
OSC20190222
OSC20191123
OSC20230401
OSC20230528
OSC20231021
OSC20240310
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
SltVA
VariableArray
WikiEngines
WikiName
YukiWiki
advcal20161205
advcal20161206
advcal20161209
advcal20161210
advcal20161215
eoml0001
eoml0002
essen_ex01_0001
impressions
kcl_malloc
khfdpl_result1
members
memo0001
memo0002
note0001
note0002
note0003
note0004
note0005
note0006
oldworks
oldworks00
oldworks06
oldworks12
oldworks13
osaskjp_index
persistent_C
populars
pr20161105
pr20161105b
scsc
seccamp2017
spam_test
uxf
uxf_01
uxf_02
uxp
* Essen Object Management Library #0002 -(by [[K]], 2017.02.20) ** レイヤ構造 -Essen:言語レイヤ --EOMLの範囲外 -ObjSys(OS) : オブジェクトの管理をするレイヤ --階層構造など -ValSys(VS) : 値の管理をするレイヤ --可変長なデータを扱いやすくする&メモリ管理&重複管理 ** 基本型 -通常データ: --intとかdoubleとか文字列型とか、まあなんでも。 --サイズが規定できればよい。型のタイプも記述する。 --可変長でもあってもいい。 -メタデータ: --通常データと似た扱いを受けるが、多少の追加サポートがある。 --(dir) (memberTable) (namelessDir) ** ValSys typedef struct Val_ { unsigned int linkCount; // プライベートの時は常に1 unsigned int hash; unsigned int flags; unsigned int siz, siz1; // siz1まではとりあえずメモリを確保してある unsigned int mini[4]; struct Val_ *typ; struct Val_ *link[2]; // 内部管理用であって、ObjSysやEssenはこれを使えない void *p; } Val; -flags: --VS_F_PUB : パブリック --VS_F_MAL : pはmallocで確保した領域を指している(=解放時にはfreeしてほしい) --VS_F_VHS : hashの値はvalidである --VS_F_EXT : pは外部のメモリ域を指している(ValSysは寿命を管理しない) --VS_F_RDO : リードオンリー属性 -データの状態にはpriとpubがある。プライベートとパブリック。 --プライベートの時は、データを共有しないので値を直接書き換えてよい。最初にアロケートした時はプライベートになる。 --パブリックの時は書き換えてはいけない。書き換えたければプライベートに戻してから書きかえる。書き換え後にパブリックに戻してよい。 --プライベートだったデータをパブリックに切り替えるとき、Valのアドレスが変化する可能性がある。またパブリックだったデータをプライベートに切り替えるときも、Valのアドレスが変化する可能性がある。しかしそれ以外の操作でアドレスが変化することはない。 ** ObjSys typedef struct Obj_ { Val *val; Val *parent; unsigned int flags; unsigned int sign; // シグネチャ これがあるから消されて再利用されたときに気付くことができる 常に非零 unsigned int linkCount; // 自分の子がこのObjを指している回数(子以外でもここを参照しているものがあれば数える) unsigend int psign; // parentのsign } Obj; -flags: --OS_F_DTY : データは改変された(これは必要だろうか?) -Valはプライべートにするかパブリックにするかでアドレスが変わるので、それを解消するために用意されるレイヤがObjSys。Objのアドレスはその変数をdelするまでずっと変わらずに存在する。 --変数名を変更しても、変数のパスを変更しても(変数を別のフォルダに移動させても)、Objのアドレスは一切変わらない。 -ルート以外のObjは一つの親を必ず持つ。 -リンクカウントが0になってもObjを消さないほうが高速だろうと思われる。 --Objのメモリを節約する観点では、こまめに消したほうがいいのだが、Objを消す最大の目的はパブリックにさせるためなので、Objのメモリを節約することは考えなくていいと思う。 ** dir (dir) { [p(Val:typ)] [n] [p(Obj), sign] [p(Obj), sign] [p(Obj), sign] ... } -それぞれのsignが0のときは、ObjではなくValへのポインタになる。 -nはsignが0ではない個数。 --nが0になったら、パブリックにできる --パブリックにしたら、親に対して「signを0にできますよ」と伝える。 -フラグがtyp側にあるといいかもしれない。 --メンバ名ソート済みフラグ、メンバ名ソート推奨フラグ、メンバ名のユニークを強制するフラグ ** メモ -[1] 高速にdirをコピーしたい --dirのポインタをすべてVal化してコピーすればよさそう(再帰的に) --プライベートが含まれている部分についてはObjのままにして頑張って比較する -[2] できるだけ高速にdirを比較したい --Val化しているものに関しては、それより下が完全に同じなので中まで比較する必要がない。
タイムスタンプを変更しない
* Essen Object Management Library #0002 -(by [[K]], 2017.02.20) ** レイヤ構造 -Essen:言語レイヤ --EOMLの範囲外 -ObjSys(OS) : オブジェクトの管理をするレイヤ --階層構造など -ValSys(VS) : 値の管理をするレイヤ --可変長なデータを扱いやすくする&メモリ管理&重複管理 ** 基本型 -通常データ: --intとかdoubleとか文字列型とか、まあなんでも。 --サイズが規定できればよい。型のタイプも記述する。 --可変長でもあってもいい。 -メタデータ: --通常データと似た扱いを受けるが、多少の追加サポートがある。 --(dir) (memberTable) (namelessDir) ** ValSys typedef struct Val_ { unsigned int linkCount; // プライベートの時は常に1 unsigned int hash; unsigned int flags; unsigned int siz, siz1; // siz1まではとりあえずメモリを確保してある unsigned int mini[4]; struct Val_ *typ; struct Val_ *link[2]; // 内部管理用であって、ObjSysやEssenはこれを使えない void *p; } Val; -flags: --VS_F_PUB : パブリック --VS_F_MAL : pはmallocで確保した領域を指している(=解放時にはfreeしてほしい) --VS_F_VHS : hashの値はvalidである --VS_F_EXT : pは外部のメモリ域を指している(ValSysは寿命を管理しない) --VS_F_RDO : リードオンリー属性 -データの状態にはpriとpubがある。プライベートとパブリック。 --プライベートの時は、データを共有しないので値を直接書き換えてよい。最初にアロケートした時はプライベートになる。 --パブリックの時は書き換えてはいけない。書き換えたければプライベートに戻してから書きかえる。書き換え後にパブリックに戻してよい。 --プライベートだったデータをパブリックに切り替えるとき、Valのアドレスが変化する可能性がある。またパブリックだったデータをプライベートに切り替えるときも、Valのアドレスが変化する可能性がある。しかしそれ以外の操作でアドレスが変化することはない。 ** ObjSys typedef struct Obj_ { Val *val; Val *parent; unsigned int flags; unsigned int sign; // シグネチャ これがあるから消されて再利用されたときに気付くことができる 常に非零 unsigned int linkCount; // 自分の子がこのObjを指している回数(子以外でもここを参照しているものがあれば数える) unsigend int psign; // parentのsign } Obj; -flags: --OS_F_DTY : データは改変された(これは必要だろうか?) -Valはプライべートにするかパブリックにするかでアドレスが変わるので、それを解消するために用意されるレイヤがObjSys。Objのアドレスはその変数をdelするまでずっと変わらずに存在する。 --変数名を変更しても、変数のパスを変更しても(変数を別のフォルダに移動させても)、Objのアドレスは一切変わらない。 -ルート以外のObjは一つの親を必ず持つ。 -リンクカウントが0になってもObjを消さないほうが高速だろうと思われる。 --Objのメモリを節約する観点では、こまめに消したほうがいいのだが、Objを消す最大の目的はパブリックにさせるためなので、Objのメモリを節約することは考えなくていいと思う。 ** dir (dir) { [p(Val:typ)] [n] [p(Obj), sign] [p(Obj), sign] [p(Obj), sign] ... } -それぞれのsignが0のときは、ObjではなくValへのポインタになる。 -nはsignが0ではない個数。 --nが0になったら、パブリックにできる --パブリックにしたら、親に対して「signを0にできますよ」と伝える。 -フラグがtyp側にあるといいかもしれない。 --メンバ名ソート済みフラグ、メンバ名ソート推奨フラグ、メンバ名のユニークを強制するフラグ ** メモ -[1] 高速にdirをコピーしたい --dirのポインタをすべてVal化してコピーすればよさそう(再帰的に) --プライベートが含まれている部分についてはObjのままにして頑張って比較する -[2] できるだけ高速にdirを比較したい --Val化しているものに関しては、それより下が完全に同じなので中まで比較する必要がない。
テキスト整形のルールを表示する