2012-04-03

POSIX使えねー

Win32 APIに慣れた身としては、POSIXが使えなさ過ぎて困る。

まず、あまりにも機能が少ない。もちろん、POSIXは環境が用意するべき最低限の保証なのだから、こういうものなのかもしれないが、低機能は低機能だ。さらに、低級だ。

そもそも、APIの設計からしてひどい。まず、関数名が暗号のように短い。Windowsのやり方DoSomethingOrOtherExW(多数の引数)が最適とは言わないが、すくなくとも、Win32 APIの方が、どういう意味なのかはわかりやすい。関数名が十分に長いので検索もしやすい。さらに統一されたドキュメントもある。今の時代、関数名が長すぎて困るということはないのだ。当時のCコンパイラーが認識する識別子の長さに関係していたのか、あるいは単にUNIX文化が略語を好むのか。

POSIXのドキュメントと格闘した挙句、結局、ほとんどの場合、Boostにもっとマシなライブラリがあるから、Boostを使ったほうがはるかに快適だということに気がついた。不思議だ。Win32 API環境でのプログラミングで、このように思ったことはない。むしろ、ネイティブのWin32 APIに比較してなんとBoostは低機能なのだろうと思ったほどだ。ところが、POSIX環境と比較すると、Boostは高機能すぎて泣けてくる。私はネイティブなやり方が好きである。ところが、POSIXの環境にきて、そのネイティブな方法が、あまりにも貧弱だということに困惑している。これは一体どういうことだ。UNIX環境ではプログラミングの整備が遅れているのか。

必然というべきなのか、UNIX環境では、多くのサードパーティによるライブラリがある。そして多くの場合、使いやすい設計と、他の環境への移植性を謳っている。

今になって気がついたのだが、Boostというのは、主にUNIX向けのライブラリなのではなかろうか。GNU/Linux環境におけるBoostは非常にありがたい存在だ。しかし、Windows環境では、それほどありがたいとも思わない。単にWin32 APIの一部の機能をC++でラップしたぐらいにしか思わない。

あるいは、やはり文化の違いなのかもしれない。Windowsではありとあらゆる便利な統一されたAPIを公式に提供しているが、UNIX環境では、そういうものはユーザー側のライブラリに任せる文化なのか。

一昔前、DirectXかOpenGLを学ぼうと考えていて色々と調べていたとき、DirectXは高機能で便利だが、OpenGLは低機能すぎるという感想を持った。なにしろ、OpenGLには文字描画さえないのだ。これも何か関係があるのだろうか。GNU/Linuxで動くOpenGLをバックエンド利用した高機能な文字列描画ライブラリは山ほどある。

そもそも、Linuxカーネルと、Win32サブシステムを含めたWindows全体を比較するのが間違っているのだろう。とはいえ、やはり統一された高機能なAPIがないのはつらい。

2 comments:

  1. ウィンドウの存在すら規格に入っていないOpenGLがフォント周りを標準規格に入れることはないでしょうね。
    一応NVIDIAがSVGやPostScriptのようなpath renderingをサポートする独自拡張を公開していて、その中でフォントを扱えます。
    これがこのまま標準に入るとはとても思えませんが。
    http://www.opengl.org/registry/specs/NV/path_rendering.txt

    ReplyDelete
  2. POSIXは、開発用のライブラリというより、カーネルに対するC言語用のインターフェイスって感じなので低機能(というか低レベル)にならざるをえないとおもいます。Linux上での開発は、オールインワンのWinと違って、必要なライブラリは自分で探してもってくる、というスタンスになるかと。ちなみにPOSIXの関数名が短いのは、初期のCコンパイラの識別子が五文字(!)制限だったことに由来するそうです。ファイル生成関数が、createでなくてcreatなのはそのせいだとか。

    ReplyDelete

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.