libapr の話 + 他
○ はじめに
下述の内容は、Apache Portable Runtime (APR) についてアリエルネットワーク CTO の inode さんが書かれた技術コラム(*)を日本語訳したモノの一部です。
氏の英語は、ネイティブが書く英語文書に比べて、とても平易で読みやすいので、そんなに間違った訳にはなっていないと思いますが、解釈の違いによって見当違いな事を言っている場合があります。
その場合には、適切にツッコンで頂けるとうれしいです。
尚、理解しにくい表現については、末尾に自分の解釈 (釈明 ?) を載せたのでツッコム前に参照して頂けるとありがたいです。
今回の話では onix 及びそれに関連する話は一切出てきません。
(*)http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial.html
○ 本編
【libapr(apache portable runtime) プログラミング・チュートリアル】
1. Tutorial Availability
最新版はこちら : http://dev.ariel-networks.com/apr/
2. libapr skelton code
新しいライブラリやフレームワークを習得する際に、まずスケルトンコードを書く事から始めると良い。スケルトンコードは短いながらも、ちゃんとコンパイルして実行できる (実際には何もしなかったりするが)。
幸いにも libapr のスケルトンコードは他のモダンなフレームワークなどよりもシンプルである。それでは apr-skelton.c を見ていこう。ここでは、apr_initialize() という初期化処理と、apr_terminate() という終了処理を呼び出しているだけだ。察しの通り、なにもしない。
libapr はフレームワークではない。なのでソフトウェアの設計全体をサポートするわけではない(*1)。 libapr には Pros と Cons というものがある。
Pros とは libapr の他のコードを簡単に使うためのものを表す。Cons とは libapr を使って開発者自身が書くコードを表す (*2)。
ここに、libapr プログラミングにはいくつかのコーディングスタイルと制限がある
・命名規則はシンプル且つ簡潔
・カプセル化
・ほとんどの戻り値は apr_status_t の型で返される
・メモリプールの制限
命名規則について。以下の例で、これらの制限が見られる
/* excerpted from mp-sample.c */
apr_status_t rv;
apr_pool_t *mp;
rv = apr_pool_create(&mp, NULL);
これから、コードの説明を行う。まずはスタイルにだけ注目してもらいたい。 apr_... という形の名前があるが、これは libapr の中で定義されたシンボルである事を表す。又、 ..._t という形は、libapr の型である事を表している。
apr_pool_t は、カプセル化された型である。これは、オブジェクトの変数が公開されておらず、これら全てがプライベート変数となる。つまりこれらに対して直接参照する事はできず、参照する場合には apr_foo_bar() といったような API を用いる。重要なのは、これらのオブジェクトをメモリに直接置く事もできず、コンストラクタによって行う(*3)。
libapr はコンストラクタとデストラクタによってのみオブジェクトの生成、廃棄を行う。
先にも少し言ったように、apr_pool_create() の戻り値の型は apr_status_t になる。こいつは、戻り値のステータスとエラーの 2 つの情報を持つ。一般的にほとんどの API が apr_status_t 型のオブジェクトを返す。なので、こいつを引数から関数の結果を得る (*4)。この手の手法は libapr で良く用いられる。
一般的に、apr_foo_t のような型があった場合には、apr_foo_bar() というような関数名を目にすると思う。この関数は apr_foo_t 型と関係している。この手の命名規則は賢人の常套手段として用いられる。
/* excerpted from mp-sample.c */
apr_status_t rv;
apr_pool_t *mp;
rv = apr_pool_create(&mp, NULL);
=== オレ流解釈 ===
(*1)
(たぶん) libapr は単なるライブラリであって、それ自身がアプリケーションではないという事を言っている (のだと思う)。なんとなくわかる気がしないでもない。
(*2)
API にお任せする部分 (Pros) と、開発者が書かなきゃいけない部分 (Cons) があるよ。という事を意味している (のだと思う)。当り前の話だが、プログラムの構造を分析すると、この二つから成り立つよという事を意味している (ような気がする)。
(*3)
apr_foo_t *foo;
int val;
foo = malloc(sizeof(apr_foo_t));
val = foo->value;
みたいな事はできず、コンストラクタを呼び出して、どこともわからない (アプリケーションが全く意識しない(できない)) 場所にオブジェクトが置かれ、参照する場合もコールバック関数から行う事を意味している (のだと思う)。
(*4)
アプリケーションはオブジェクトがどこにあるか意識していないので、apr_status_t オブジェクトを取り出す為の API を呼び出す事で、関数の結果を知るのだ、という事を意味している (のだと思う)。
○ 新しい事
新しい事を始めると、気分は非常にワクワクする。自分にとって、今立っているこの領域に到達するケースは極めて稀である。自分という人間は新しい事に対して、非常に及び腰になる。世の中のほとんどのモノが『食わず嫌い』ならぬ、『知らず嫌い』である。
きっかけはどうあれ、実際に物事を始めるという行為に至る事は自分にとっては珍しい事であり、また、ある物事に興味を持つというのはとても良いことであると個人的に思ってる。
このワクワクが、一体いつまで続くのか不明だが、少なくとも当初湧いた疑問はまだわかってないので、ここで燃焼し切りたくはない。かつてのように、これが好循環にはまると、人生がより楽しくなると思うので、しばらくは継続的に調べる事にする。
ちなみに libapr を調べ始めたきっかけは、メモリプールという謎の存在を調べたいという程度のものである。
この謎がまた少しわかったら、また書くことにする。
下述の内容は、Apache Portable Runtime (APR) についてアリエルネットワーク CTO の inode さんが書かれた技術コラム(*)を日本語訳したモノの一部です。
氏の英語は、ネイティブが書く英語文書に比べて、とても平易で読みやすいので、そんなに間違った訳にはなっていないと思いますが、解釈の違いによって見当違いな事を言っている場合があります。
その場合には、適切にツッコンで頂けるとうれしいです。
尚、理解しにくい表現については、末尾に自分の解釈 (釈明 ?) を載せたのでツッコム前に参照して頂けるとありがたいです。
今回の話では onix 及びそれに関連する話は一切出てきません。
(*)http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial.html
○ 本編
【libapr(apache portable runtime) プログラミング・チュートリアル】
1. Tutorial Availability
最新版はこちら : http://dev.ariel-networks.com/apr/
2. libapr skelton code
新しいライブラリやフレームワークを習得する際に、まずスケルトンコードを書く事から始めると良い。スケルトンコードは短いながらも、ちゃんとコンパイルして実行できる (実際には何もしなかったりするが)。
幸いにも libapr のスケルトンコードは他のモダンなフレームワークなどよりもシンプルである。それでは apr-skelton.c を見ていこう。ここでは、apr_initialize() という初期化処理と、apr_terminate() という終了処理を呼び出しているだけだ。察しの通り、なにもしない。
libapr はフレームワークではない。なのでソフトウェアの設計全体をサポートするわけではない(*1)。 libapr には Pros と Cons というものがある。
Pros とは libapr の他のコードを簡単に使うためのものを表す。Cons とは libapr を使って開発者自身が書くコードを表す (*2)。
ここに、libapr プログラミングにはいくつかのコーディングスタイルと制限がある
・命名規則はシンプル且つ簡潔
・カプセル化
・ほとんどの戻り値は apr_status_t の型で返される
・メモリプールの制限
命名規則について。以下の例で、これらの制限が見られる
/* excerpted from mp-sample.c */
apr_status_t rv;
apr_pool_t *mp;
rv = apr_pool_create(&mp, NULL);
これから、コードの説明を行う。まずはスタイルにだけ注目してもらいたい。 apr_... という形の名前があるが、これは libapr の中で定義されたシンボルである事を表す。又、 ..._t という形は、libapr の型である事を表している。
apr_pool_t は、カプセル化された型である。これは、オブジェクトの変数が公開されておらず、これら全てがプライベート変数となる。つまりこれらに対して直接参照する事はできず、参照する場合には apr_foo_bar() といったような API を用いる。重要なのは、これらのオブジェクトをメモリに直接置く事もできず、コンストラクタによって行う(*3)。
libapr はコンストラクタとデストラクタによってのみオブジェクトの生成、廃棄を行う。
先にも少し言ったように、apr_pool_create() の戻り値の型は apr_status_t になる。こいつは、戻り値のステータスとエラーの 2 つの情報を持つ。一般的にほとんどの API が apr_status_t 型のオブジェクトを返す。なので、こいつを引数から関数の結果を得る (*4)。この手の手法は libapr で良く用いられる。
一般的に、apr_foo_t のような型があった場合には、apr_foo_bar() というような関数名を目にすると思う。この関数は apr_foo_t 型と関係している。この手の命名規則は賢人の常套手段として用いられる。
/* excerpted from mp-sample.c */
apr_status_t rv;
apr_pool_t *mp;
rv = apr_pool_create(&mp, NULL);
=== オレ流解釈 ===
(*1)
(たぶん) libapr は単なるライブラリであって、それ自身がアプリケーションではないという事を言っている (のだと思う)。なんとなくわかる気がしないでもない。
(*2)
API にお任せする部分 (Pros) と、開発者が書かなきゃいけない部分 (Cons) があるよ。という事を意味している (のだと思う)。当り前の話だが、プログラムの構造を分析すると、この二つから成り立つよという事を意味している (ような気がする)。
(*3)
apr_foo_t *foo;
int val;
foo = malloc(sizeof(apr_foo_t));
val = foo->value;
みたいな事はできず、コンストラクタを呼び出して、どこともわからない (アプリケーションが全く意識しない(できない)) 場所にオブジェクトが置かれ、参照する場合もコールバック関数から行う事を意味している (のだと思う)。
(*4)
アプリケーションはオブジェクトがどこにあるか意識していないので、apr_status_t オブジェクトを取り出す為の API を呼び出す事で、関数の結果を知るのだ、という事を意味している (のだと思う)。
○ 新しい事
新しい事を始めると、気分は非常にワクワクする。自分にとって、今立っているこの領域に到達するケースは極めて稀である。自分という人間は新しい事に対して、非常に及び腰になる。世の中のほとんどのモノが『食わず嫌い』ならぬ、『知らず嫌い』である。
きっかけはどうあれ、実際に物事を始めるという行為に至る事は自分にとっては珍しい事であり、また、ある物事に興味を持つというのはとても良いことであると個人的に思ってる。
このワクワクが、一体いつまで続くのか不明だが、少なくとも当初湧いた疑問はまだわかってないので、ここで燃焼し切りたくはない。かつてのように、これが好循環にはまると、人生がより楽しくなると思うので、しばらくは継続的に調べる事にする。
ちなみに libapr を調べ始めたきっかけは、メモリプールという謎の存在を調べたいという程度のものである。
この謎がまた少しわかったら、また書くことにする。
2009-01-08 02:55
nice!(0)
コメント(0)
トラックバック(0)
コメント 0