Entry

クロスプラットフォームのポリシーとライブラリ構成の話

2009年06月14日

仕事/趣味を問わず,普段のプログラミングではアプリよりもライブラリを作っていることが多いんですけれど,そこで毎度のことながら悩ましく思ってることに,OS 固有の API を使うか,ANSI の標準関数を使うかってなことがあります。

例えば,ファイルを開くとき,標準関数では fopen(3) を使いますよね。けど,Windows API では,ファイル(というかリソース一般)を開くのに,CreateFile() という関数が用意されています。本家はこちら。POSIX でも,マニュアル番号を見ても分かるとおり,fopen(3) の実装がそのままシステムコールになるわけではなくて,open(2) のシステムコールを使ってファイルを開くことになります。fopen(3) は,内部的にそれぞれの OS に合わせたシステムコールを呼ぶように実装されているわけで,言ってみれば,システムコール間の差異を吸収するラッパのような役割を持っています。

システムコールを最終的に呼ぶようなライブラリを作る場合(大抵の場合はそうだけど),ここら辺を考慮する必要があって,ネイティブ API を呼び出しをライブラリを書き込んでしまうと,他の環境で確実に動かなくなってしまいます。一方で,ネイティブ API は,OS に固有の属性を細かく設定できるし,効率の面から言っても優れていることが多い。ここら辺のトレードオフをどう考えるかが難しいわけです。

実例を挙げると,例えば fopen(3) の場合,ファイル名を指定する第1引数には,ANSI 文字列を指定することになってますよね。けど,Windows NT 系の OS の場合,Windows のファイル名は UTF-16LE を内部で使うので(厳密に言うとちと違うらしいのだが),できれば UTF-16 でファイル名を指定できるようにしたい。こゆときは,fopen(3) は使えないわけで,Windows CLR を使うにしても,_wfopen_s() とか _tfopen_s() のような非標準関数を使わなくちゃいけません。それだったら,システムコールを読んじゃった方がいんでね?とは思うんだけれども。

近頃は OS の種類が増えてきたので,ライブラリを作るにしても,ポータビリティの重要性が叫ばれています。けど,特定の OS でしか使わないことが明らかなライブラリでも標準関数を使うのは,YANGI 的になってしまうことがあったりする。悩ましいんですけどね。そんな感じ。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN