今、gnakoを使って少し大きめのアプリ書いてるんですが…。
gnakoの問題点が色々分かって、やっぱりGUIのエディタは
別のモノを使ったほうがいいんじゃないかと。通信DLLは
大体出来てるので、この辺り片付けたら、次はWinAPIを
もうちょっとダイレクトに触れるDLLなりexeなり作ろうかなあ。
さて、今回は「少し大きめのアプリ」でも使ってるカレンダー
機能のお話し。なでしこのくみこみ関数使ってある程度は
できるんですが、GUI用に使うならこれぐらいは欲しいかなあ
と言う部分を補完。
------ここから------
■GRP年月日
・｛整数｝年
・｛整数｝月
・｛整数｝日数
・日
・日数設定～
日数＝月日数判断（年、月）
・曜日設定～
日数回
年月日＝「｛年｝」＆「/」＆「｛月｝」＆「/」＆「｛回数｝」
日\回数＝年月日の曜日
●二月日数判断（Yの）
もしYを4で割った余り＝0ならば
もしYを100で割った余り＝0ならば
もしYを400で割った余り＝0ならば
日数＝29
違えば
日数＝28
違えば
日数＝29
違えば
日数＝28
日数で戻る
●月日数判断（Y、M）
Mで条件分岐
1ならば
日数＝31
2ならば
日数＝Yの二月日数判断
3ならば
日数＝31
4ならば
日数＝30
5ならば
日数＝31
6ならば
日数＝30
7ならば
日数＝31
8ならば
日数＝31
9ならば
日数＝30
10ならば
日数＝31
11ならば
日数＝30
12ならば
日数＝31
違えば
日数＝0
日数で戻る
------ここまで------
こんなもんでしょうか。「■GRP年月日」がカレンダー情報を
保持していて、要素「日」は配列です。「年」と「月」を設定して
「日数設定」メソッドと、「曜日設定」メソッドを呼べば、「日数」
にその月が何日あるかと、「日」にそれぞれの日が何曜日か
を代入します。「日」は配列の添え字（0～）が日（1～）に対応
してます。
アルゴリズム的にはC言語とそんなに変わらない感じ。なでしこは
グループ昨日を使いこなしていけばそこそこ複雑なことも出きる
ので、「なでしこでアルゴリズム」みたいな本があれば面白いのに
なあ。
2013年10月22日火曜日
2013年10月6日日曜日
【なでしこ】グループをシリアライズしてみる
ああ、なんか時間取れない…と思ってるウチにかなり時間が
開いてしまった(￣ω￣;。
DLLの話はちょっとおいておいて、なでしこのグループの話。
なでしこのグループを作成して、それをいったんファイルに保存
しておき、今度ファイルからよんでまたグループに値を代入する
と言うお話。なでしこは中間コードを生成するわけではないので
ホントにシリアライズは出来ないんだけど、まあイベントとか
関数とか含まないグループならファイルに保存するぐらいなら
可能かな。
ってことでまずはグループを作ってみます。
------ここから------
■GRPプロジェクト
・｛文字列｝GRP名｛=「GRPプロジェクト」｝
・｛整数｝ノード｛=0｝
・｛文字列｝名前
・｛文字列｝開始日
・｛文字列｝終了日
・｛整数｝次ノード｛=1｝
------ここまで------
実はちょっと仕掛けが必要で、グループ要素の先頭に
文字列で「GRPプロジェクト」と、グループ名(GRP名）を
入れておきます。あとは文字列とか整数とかで値を列挙。
＃あるプログラム用なので、要素名とかはあまり気に
しないでください(^^;。
これをファイルに保存しておきたい分けですが、折角
だからXML風に保存します。
------ここから------
<GRPプロジェクト>
<コード>0</コード>
<名前>IIU向け新PFの開発</名前>
<開始日>2013/10/04</開始日>
<終了日></終了日>
<関係者コード>100</関係者コード>
<管理項目コード>200</管理項目コード>
<フェーズコード>300</フェーズコード>
</GRPプロジェクト>
------ここまで------
グループ名が<GRPプロジェクト>～</GRPプロジェクト>の
タグになって、あとは要素がそれぞれのタグとなります。
これを実現するのに、下記のコードを書きました。
------ここから------
●XML化（GRPを）
GRP名＝GRPのグループ判定
もしGRP名＝空ならば
＃何もしない
違えば
メンバーズはGRPのメンバ詳細列挙
メンバ数はメンバーズの配列要素数
メンバ数回
メンバーズ\（回数-1）の「(」から「)」まで範囲切り取る
タグペアはメンバーズ\（回数-1）を「 = 」で区切る
もし（回数-1）=0ならば
グループ終了タグ＝「</」＆「｛タグペア\1｝」＆「>」
XML結果＝「<」＆「｛タグペア\1｝」＆「>」＆改行
違えば
アイテム開始タグ＝「 」＆「<」＆「｛タグペア\0｝」＆「>」
アイテム終了タグ＝「</」＆「｛タグペア\0｝」＆「>」
XML結果＝XML結果＆アイテム開始タグ＆「｛タグペア\1｝」＆アイテム終了タグ＆改行
XML結果＝XML結果＆グループ終了タグ＆改行＆改行
XML結果で戻る
------ここまで------
開いてしまった(￣ω￣;。
DLLの話はちょっとおいておいて、なでしこのグループの話。
なでしこのグループを作成して、それをいったんファイルに保存
しておき、今度ファイルからよんでまたグループに値を代入する
と言うお話。なでしこは中間コードを生成するわけではないので
ホントにシリアライズは出来ないんだけど、まあイベントとか
関数とか含まないグループならファイルに保存するぐらいなら
可能かな。
ってことでまずはグループを作ってみます。
------ここから------
■GRPプロジェクト
・｛文字列｝GRP名｛=「GRPプロジェクト」｝
・｛整数｝ノード｛=0｝
・｛文字列｝名前
・｛文字列｝開始日
・｛文字列｝終了日
・｛整数｝次ノード｛=1｝
実はちょっと仕掛けが必要で、グループ要素の先頭に
文字列で「GRPプロジェクト」と、グループ名(GRP名）を
入れておきます。あとは文字列とか整数とかで値を列挙。
＃あるプログラム用なので、要素名とかはあまり気に
しないでください(^^;。
これをファイルに保存しておきたい分けですが、折角
だからXML風に保存します。
------ここから------
<GRPプロジェクト>
<コード>0</コード>
<名前>IIU向け新PFの開発</名前>
<開始日>2013/10/04</開始日>
<終了日></終了日>
<関係者コード>100</関係者コード>
<管理項目コード>200</管理項目コード>
<フェーズコード>300</フェーズコード>
</GRPプロジェクト>
グループ名が<GRPプロジェクト>～</GRPプロジェクト>の
タグになって、あとは要素がそれぞれのタグとなります。
これを実現するのに、下記のコードを書きました。
------ここから------
●XML化（GRPを）
GRP名＝GRPのグループ判定
もしGRP名＝空ならば
＃何もしない
違えば
メンバーズはGRPのメンバ詳細列挙
メンバ数はメンバーズの配列要素数
メンバ数回
メンバーズ\（回数-1）の「(」から「)」まで範囲切り取る
タグペアはメンバーズ\（回数-1）を「 = 」で区切る
もし（回数-1）=0ならば
グループ終了タグ＝「</」＆「｛タグペア\1｝」＆「>」
XML結果＝「<」＆「｛タグペア\1｝」＆「>」＆改行
違えば
アイテム開始タグ＝「 」＆「<」＆「｛タグペア\0｝」＆「>」
アイテム終了タグ＝「</」＆「｛タグペア\0｝」＆「>」
XML結果＝XML結果＆アイテム開始タグ＆「｛タグペア\1｝」＆アイテム終了タグ＆改行
XML結果＝XML結果＆グループ終了タグ＆改行＆改行
XML結果で戻る
「グループ判定」「メンバ詳細列挙」というのはなでしこの命令です。
一番最初なら大くくりのタグを作って、2番目以降は1行に開始
タグと終了タグを入れてます。
ファイルから呼んでグループに戻すのは…省略(^^;。比較的簡単に
出来ますよ。最初のタグ読んだときにグループを生成し、それ以降は
生成したグループに値（<xxxx>～</xxxx>の間にある文字列）を入れる
だけ。
なでしこの変数はファジーに出来ていて、
｛整数｝X
と宣言したところにたとえば文字列で「1」と入れてあげても、以降
ちゃんと整数として扱ってくれます（2byte系の文字列「１」ではダメ
でした。半角数字なら 整数として代入してくれるようです）。なので
ファイルに文字列として書き出していても、次にそれを読み込んで
変数に代入すれば整数として扱ってくれるんですね～♪
2013年9月15日日曜日
【なでしこ】プラグインを作ってみる ～実装編 管理用構造体を作る～
さて、設計したプラグインをいよいよ実装するわけですが、
今回はなでしこから見ると全部「ハンドル」として見えるので、
DLL側で全てのハンドルを管理できる構造体を作成します。
------ここから------
typedef struct
{
int index;
unsigned long flag;
int size;
CRITICAL_SECTION crit;
union
{
unsigned long byte_hdl;
unsigned char b[4];
void *buf_hdl;
void *list_hdl;
FILE *fp_hdl;
int sock_hdl;
HANDLE ser_hdl;
}u;
void *pextend;
void *pprev;
void *pnext;
}COMM_HANDLE;
------ここまで------
このプラグインは主に通信用途と、一般的なC的関数の実装
を意識したのでCommunication, Commonを意識して"COMM_"
としました。
構造自体は簡単で、unionの中にハンドル本体を保存する
変数、もしくはポインタが配置されてます。1,2,4byteのバイト
配列はunsigned char, unsigned short, unsigned longに相当
するものとして、これは構造体の中で値を管理します。
その他のハンドルはポインタです。あ、socketはポインタ
じゃなかったな(^^;。
pextendは各ハンドルに対して付加的な情報が必要な場合に
使用します。pprevとpnextはキューとかスタックをリスト構造で
管理してるので、それらを管理する場合にこの構造体を
連結するためのものです。
実際、なでしこの各変数もこれに近い構造体で管理している
ので、こういう言語拡張系のDLLではまずまず一般的な
形なのではないかと思います。
今回はなでしこから見ると全部「ハンドル」として見えるので、
DLL側で全てのハンドルを管理できる構造体を作成します。
------ここから------
typedef struct
{
int index;
unsigned long flag;
int size;
CRITICAL_SECTION crit;
union
{
unsigned long byte_hdl;
unsigned char b[4];
void *buf_hdl;
void *list_hdl;
FILE *fp_hdl;
int sock_hdl;
HANDLE ser_hdl;
}u;
void *pextend;
void *pprev;
void *pnext;
}COMM_HANDLE;
このプラグインは主に通信用途と、一般的なC的関数の実装
を意識したのでCommunication, Commonを意識して"COMM_"
としました。
構造自体は簡単で、unionの中にハンドル本体を保存する
変数、もしくはポインタが配置されてます。1,2,4byteのバイト
配列はunsigned char, unsigned short, unsigned longに相当
するものとして、これは構造体の中で値を管理します。
その他のハンドルはポインタです。あ、socketはポインタ
じゃなかったな(^^;。
pextendは各ハンドルに対して付加的な情報が必要な場合に
使用します。pprevとpnextはキューとかスタックをリスト構造で
管理してるので、それらを管理する場合にこの構造体を
連結するためのものです。
実際、なでしこの各変数もこれに近い構造体で管理している
ので、こういう言語拡張系のDLLではまずまず一般的な
形なのではないかと思います。
2013年9月9日月曜日
【なでしこ】お、イベント発生成功！
どうもプログラムが間違っていたらしく、DLLでイベント発生成功！。思ってた
通り、
------ここから------
if (arg1->VType == varGroup)
{
ret = pfnako->nako_group_findMember(arg1, "発生した時");
if (ret->VType != varNil)
{
pfnako->nako_group_exec(arg1, "発生した時");
}
else
{
/*Do Nothing*/
;
}
}
------ここまで------
の様なコード書いておいて、なでしこ側で
------ここから------
■テストグループ
・｛イベント｝発生した時
G1とはテストグループ
G1→発生した時は～
「イベント発生」と表示
DLL引数ダンプ（G1） /*ここでDLLの関数をコール。グループを渡す*/
------ここまで------
と、やってやると、テストグループのイベントをDLL側からコールできました(^^)。
これで今までなでしこ→DLLの一方方向なコールシーケンスしか出来なかった
けど、DLL→なでしこなコールシーケンスも書ける！。ただし、一旦なでしこ定義の
関数に処理が渡ってること考えると、スレッドセーフではない気はします。
セマフォとか同期処理を上手く入れてやればDLL側のスレッドでもコールできる
かも…。
通り、
------ここから------
if (arg1->VType == varGroup)
{
ret = pfnako->nako_group_findMember(arg1, "発生した時");
if (ret->VType != varNil)
{
pfnako->nako_group_exec(arg1, "発生した時");
}
else
{
/*Do Nothing*/
;
}
}
------ここまで------
の様なコード書いておいて、なでしこ側で
------ここから------
■テストグループ
・｛イベント｝発生した時
G1とはテストグループ
G1→発生した時は～
「イベント発生」と表示
DLL引数ダンプ（G1） /*ここでDLLの関数をコール。グループを渡す*/
------ここまで------
と、やってやると、テストグループのイベントをDLL側からコールできました(^^)。
これで今までなでしこ→DLLの一方方向なコールシーケンスしか出来なかった
けど、DLL→なでしこなコールシーケンスも書ける！。ただし、一旦なでしこ定義の
関数に処理が渡ってること考えると、スレッドセーフではない気はします。
セマフォとか同期処理を上手く入れてやればDLL側のスレッドでもコールできる
かも…。
2013年9月8日日曜日
【なでしこ】イベントで行き詰る(￣ω￣;
なでしこのグループを作った際
------ここから------
■Gテスト
・｛イベント｝テスト動作した時
------ここまで------
みたいな感じで、イベントをかけるんですが、これを関数の引数として
DLLに渡すと、案の定PHiValueで渡ってきます。まあ、ここまでは
配列であれ整数であれ一緒なので予想通りだったんですが…
この”イベント”についてnako_group_exec()と言う関数が定義してあって
どうもグループのイベントを検索して実行できるっぽいんだけど…出来ない
（￣□￣；。これが出きると、なでしこ側で定義した「関数」っぽいものを
DLL側からコールできるので、DLL側でイベントを発生させてそれに合わ
せてなでしこの動きを制御できるはずだったんだけどなあ。
もうちょっと調べてみるか。
------ここから------
■Gテスト
・｛イベント｝テスト動作した時
------ここまで------
みたいな感じで、イベントをかけるんですが、これを関数の引数として
DLLに渡すと、案の定PHiValueで渡ってきます。まあ、ここまでは
配列であれ整数であれ一緒なので予想通りだったんですが…
この”イベント”についてnako_group_exec()と言う関数が定義してあって
どうもグループのイベントを検索して実行できるっぽいんだけど…出来ない
（￣□￣；。これが出きると、なでしこ側で定義した「関数」っぽいものを
DLL側からコールできるので、DLL側でイベントを発生させてそれに合わ
せてなでしこの動きを制御できるはずだったんだけどなあ。
もうちょっと調べてみるか。
2013年8月31日土曜日
【なでしこ】プラグインDLLの中身
なでしこのDLLに含まれる（なでしこから呼ばれる）関数はそんなに多くなく、
・ImportNakoFunction
・PluginInfo
・PluginVersion
・PluginRequire
・PluginInit
・PluginFin
の6つです。この内、自分でせっせといじる必要があるのは
・ImportNakoFunction
で、この中で自分の作成した関数（命令）を登録します。 たとえば、なでしこから
DLLに渡ってくる引数のチェックをする関数を作ったとします。
------ここから------
void _disp_nakovar(PHiValue pvar)
{
if (pvar != NULL)
{
switch (pvar->VType)
{
case varNil :
DBGPRINTF("Var is Nil(%d)\n", pvar->VType);
break;
case varInt :
DBGPRINTF("Var is Int(%d)\n", pvar->VType);
break;
case varStr :
DBGPRINTF("Var is Str(%d)\n", pvar->VType);
break;
default :
DBGPRINTF("Var is Unknown(%d)\n", pvar->VType);
break;
}
}
}
------ここまで------
あ、デバッグ用に作ったのでDBGPRINTF()とかなってますが、
中身はprintf()です。 PHiValuはなでしこの変数を格納するための
構造体（へのポインタ）で、これに変数の種類とかいろいろ書いて
ありあす。途中省略してますが、この構造体の中身みれば、
大体のことが分かります（…って言うか、なでしこからDLLに
渡される情報はこの構造体が全てです(^^; ）。
このままではなでしこに登録できませんので、なでしこの命令と
して登録できる形の関数を書く必要があります。
------ここから------
PHiValue __stdcall dnako_varchk(DWORD h)
{
PHiValue arg1 = 0;
PHiValue ret = 0;
NAKO_FUNCS *pfnako = _get_nako_funcs();
DBGPRINTF("Enter -- %s()\n", __FUNCTION__);
arg1 = pfnako->nako_getFuncArg(h, 0);
ret = pfnako->nako_var_new(NULL);
DBGVARCHK(arg1);
return(ret);
}
------ここまで------
なでしこに登録する命令は常にこの形になっています。
PHiValue __stdcall dnako_varchk(DWORD h)
は、戻り値がPHiValue、Windowsの関数コール規約__stdcall、関数名が
dnako_varchk（これはユーザーが任意に名前つけられます）、引数は
DWORD型のh一つだけとなります。
命令の引数から実際の変数を取得する場合は
・pfnako->nako_getFuncArg(h, 0)
を使用します。pfnakoは関数セットを構造体として持っていて、
そこへのポインタです。この関数を実行することで、引数のh
から、PHiValueの変数を引っ張ってこれる仕組みです。
命令の引数が複数ある場合は、
arg1 = pfnako->nako_getFuncArg(h, 0);
arg2 = pfnako->nako_getFuncArg(h, 1);
arg3 = pfnako->nako_getFuncArg(h, 2);
と、引数分実行すれば順番に取得できます。つまりnako_getFuncArg()
の第二引数は、変数のリストだか配列だかのインデックスってこと
ですね。先頭のインデックスは0です。
こうやって取得したarg1はPHiValue型ですので、必要に応じてここから
整数や文字列を取り出します。pfnakoの中に、
・nako_var2int() /*PHiValueからint型の値取り出し*/
・nako_var2str() /*PHiValueから文字列取り出し*/
などがあるので、必要に応じて使用します。
最後に、この関数はデバッグ用だったので、戻り値は特に必要なかった
ですが、実際に必要な場合には、
・ret = pfnako->nako_var_new(NULL);
でPHiValue型の空の変数を作成した後、
・nako_int2var()
などを使用して、PHiValue型に実際をセットし、これをなでしこに返します。
すると、それがなでしこ命令を実行した際の戻り値になるわけですね～♪
最後はこのdnako_varchk()をなでしこに登録します。上でも書きましたが
登録するのは、
ImportNakoFunction()の中身でやります。
------ここから------
NAKO_API(void) ImportNakoFunction(void)
{
NAKO_FUNCS *pfnako = _get_nako_funcs();
DBGPRINTF("Enter -- ImportNakoFunction()\n");
pfnako->nako_addFunction("DLL引数ダンプ", "A", dnako_varchk, 0);
}
------ここまで------
・pfnako->nako_addFunction("DLL引数ダンプ", "A", dnako_varchk, 0);
が実際に登録してる場所で、"DLL引数ダンプ"はなでしこの命令名、
"A"がその時の引数、 "dnako_varchk"が上で作ったCの関数名です。
最後の0は…分かりませんヾ(;´▽｀A``。サンプルに0が設定されてたので
0にしてあります…。
なでしこ命令の引数ですが、"A"と書いた部分に"A,B"と書いておけば
引数が2つってことになります。またここに"Aの"とか書いておけば、
なでしこ命令としても「AのDLL引数ダンプ」みたいに書けます。上の
場合は
・DLL引数ダンプ（A）
と、ちょっとC言語っぽくなりますが、今回は引数が多めの命令も
ありますので、これで統一します。
・ImportNakoFunction
・PluginInfo
・PluginVersion
・PluginRequire
・PluginInit
・PluginFin
の6つです。この内、自分でせっせといじる必要があるのは
・ImportNakoFunction
で、この中で自分の作成した関数（命令）を登録します。 たとえば、なでしこから
DLLに渡ってくる引数のチェックをする関数を作ったとします。
------ここから------
void _disp_nakovar(PHiValue pvar)
{
if (pvar != NULL)
{
switch (pvar->VType)
{
case varNil :
DBGPRINTF("Var is Nil(%d)\n", pvar->VType);
break;
case varInt :
DBGPRINTF("Var is Int(%d)\n", pvar->VType);
break;
case varStr :
DBGPRINTF("Var is Str(%d)\n", pvar->VType);
break;
default :
DBGPRINTF("Var is Unknown(%d)\n", pvar->VType);
break;
}
}
}
------ここまで------
あ、デバッグ用に作ったのでDBGPRINTF()とかなってますが、
中身はprintf()です。 PHiValuはなでしこの変数を格納するための
構造体（へのポインタ）で、これに変数の種類とかいろいろ書いて
ありあす。途中省略してますが、この構造体の中身みれば、
大体のことが分かります（…って言うか、なでしこからDLLに
渡される情報はこの構造体が全てです(^^; ）。
このままではなでしこに登録できませんので、なでしこの命令と
して登録できる形の関数を書く必要があります。
------ここから------
PHiValue __stdcall dnako_varchk(DWORD h)
{
PHiValue arg1 = 0;
PHiValue ret = 0;
NAKO_FUNCS *pfnako = _get_nako_funcs();
DBGPRINTF("Enter -- %s()\n", __FUNCTION__);
arg1 = pfnako->nako_getFuncArg(h, 0);
ret = pfnako->nako_var_new(NULL);
DBGVARCHK(arg1);
return(ret);
}
------ここまで------
なでしこに登録する命令は常にこの形になっています。
PHiValue __stdcall dnako_varchk(DWORD h)
は、戻り値がPHiValue、Windowsの関数コール規約__stdcall、関数名が
dnako_varchk（これはユーザーが任意に名前つけられます）、引数は
DWORD型のh一つだけとなります。
命令の引数から実際の変数を取得する場合は
・pfnako->nako_getFuncArg(h, 0)
を使用します。pfnakoは関数セットを構造体として持っていて、
そこへのポインタです。この関数を実行することで、引数のh
から、PHiValueの変数を引っ張ってこれる仕組みです。
命令の引数が複数ある場合は、
arg1 = pfnako->nako_getFuncArg(h, 0);
arg2 = pfnako->nako_getFuncArg(h, 1);
arg3 = pfnako->nako_getFuncArg(h, 2);
と、引数分実行すれば順番に取得できます。つまりnako_getFuncArg()
の第二引数は、変数のリストだか配列だかのインデックスってこと
ですね。先頭のインデックスは0です。
こうやって取得したarg1はPHiValue型ですので、必要に応じてここから
整数や文字列を取り出します。pfnakoの中に、
・nako_var2int() /*PHiValueからint型の値取り出し*/
・nako_var2str() /*PHiValueから文字列取り出し*/
などがあるので、必要に応じて使用します。
最後に、この関数はデバッグ用だったので、戻り値は特に必要なかった
ですが、実際に必要な場合には、
・ret = pfnako->nako_var_new(NULL);
でPHiValue型の空の変数を作成した後、
・nako_int2var()
などを使用して、PHiValue型に実際をセットし、これをなでしこに返します。
すると、それがなでしこ命令を実行した際の戻り値になるわけですね～♪
最後はこのdnako_varchk()をなでしこに登録します。上でも書きましたが
登録するのは、
ImportNakoFunction()の中身でやります。
------ここから------
NAKO_API(void) ImportNakoFunction(void)
{
NAKO_FUNCS *pfnako = _get_nako_funcs();
DBGPRINTF("Enter -- ImportNakoFunction()\n");
pfnako->nako_addFunction("DLL引数ダンプ", "A", dnako_varchk, 0);
}
------ここまで------
・pfnako->nako_addFunction("DLL引数ダンプ", "A", dnako_varchk, 0);
が実際に登録してる場所で、"DLL引数ダンプ"はなでしこの命令名、
"A"がその時の引数、 "dnako_varchk"が上で作ったCの関数名です。
最後の0は…分かりませんヾ(;´▽｀A``。サンプルに0が設定されてたので
0にしてあります…。
なでしこ命令の引数ですが、"A"と書いた部分に"A,B"と書いておけば
引数が2つってことになります。またここに"Aの"とか書いておけば、
なでしこ命令としても「AのDLL引数ダンプ」みたいに書けます。上の
場合は
・DLL引数ダンプ（A）
と、ちょっとC言語っぽくなりますが、今回は引数が多めの命令も
ありますので、これで統一します。
2013年8月24日土曜日
【なでしこ】プラグインを作ってみる ～設計編 その10～
最後はハンドル自体に対する関数です。
------ここから------
・ハンドルタイプ取得
書式：ハンドルタイプ（[int]ハンドル）
戻値：[int]ハンドルタイプ
説明：指定ハンドルの種別を取得する。戻り値は以下のとおり。
-1 ：エラー（使われてない、など）
1 ：バイト
2 ：バッファ（リングバッファ）
4 ：ファイル
8 ：キュー
16 ：スタック
32 ：ソケット
64 ：シリアルポート
・ハンドル解放
書式：ハンドル解放（[int]ハンドル）
戻値：なし
説明：取得したハンドルを解放する。対象がメモリの場合はメモリ
が解放され、バイナリ（ファイル）やソケットの場合は
それらがクローズされる。
------ここまで------
キューとかスタックにハンドルをつないだ場合、取得した際のタイプが
分からないのでそれを取得できる関数を用意します。
各関数群で「ハンドルを確保」した場合は、それを使わなくなった時点で
「ハンドル解放」します。ガーベージコレクトの様な高度な処理は内部で
持ってませんのでヾ(;´▽｀A``。
尚、解放時、ハンドルのタイプによって実施する処理は違ってるんですが
それはこの関数内部で判断して実施してるので、とにかくいらなくなったら
解放してください(^^;。
------ここから------
・ハンドルタイプ取得
書式：ハンドルタイプ（[int]ハンドル）
戻値：[int]ハンドルタイプ
説明：指定ハンドルの種別を取得する。戻り値は以下のとおり。
-1 ：エラー（使われてない、など）
1 ：バイト
2 ：バッファ（リングバッファ）
4 ：ファイル
8 ：キュー
16 ：スタック
32 ：ソケット
64 ：シリアルポート
・ハンドル解放
書式：ハンドル解放（[int]ハンドル）
戻値：なし
説明：取得したハンドルを解放する。対象がメモリの場合はメモリ
が解放され、バイナリ（ファイル）やソケットの場合は
それらがクローズされる。
------ここまで------
キューとかスタックにハンドルをつないだ場合、取得した際のタイプが
分からないのでそれを取得できる関数を用意します。
各関数群で「ハンドルを確保」した場合は、それを使わなくなった時点で
「ハンドル解放」します。ガーベージコレクトの様な高度な処理は内部で
持ってませんのでヾ(;´▽｀A``。
尚、解放時、ハンドルのタイプによって実施する処理は違ってるんですが
それはこの関数内部で判断して実施してるので、とにかくいらなくなったら
解放してください(^^;。
登録:
投稿 (Atom)