はらぺこ日誌

ご無沙汰ぶりです…。

以前、wchar_t はどうにも使い物にならないからどうしよう、といった記事を書いたのですが、その続きのお話です。

表題の通りで、 libiconv を用いて文字セットを自動認識する処理のサンプルを書いてみました。詳しい経緯はTicket 内で逐次コメントしています。
(続きを読む…)

otoco に限らず、 PC 上で動作するプログラムの多くは、テキストを処理することを目的の一部またはすべてとしています。 otoco の場合は特に、どこの誰とも分からない人が MML を書き、それを読み込んで XML やら SMF やらオーディオやら楽譜やらに変換することを目的としているので、どこの誰が MML を (あるいは XML を直接) 書いても問題なく処理できるよう、文字セットの扱いには丁重でなければなりません。

当初の方針として、 otoco では内部コードに Unicode を使用し、その物理型は wchar_t で扱うつもりでいました。この辺、C/C++ でのクロスプラットフォーム開発に慣れていないと陥りやすい罠であるように思うのですが… 現状の wchar_t ははっきり言ってクロスプラットフォーム開発には向いていないものといわざるを得ないようです。

とりあえず確認しているのは Windows の VC++ 2008 と Linux の gcc だけなのですが、それだけでも調べた限りで以下のような相違点がありました。

(続きを読む…)

制御命令一覧の転載が完了しました。

otoco の制御命令は Perl 版でも実装実績がまだ無く、仕様に関しても、構想はあるんだけれども内容は埋まらないまま穴だらけ、という状態です。メタイベントの類とか、むしろ実装が容易な上にプライオリティも高そうなものが未定義のままほったらかしですね…。早いとこどうにかしないと。

すでに仕様が埋まっている制御命令にもいくつか問題があります。まず #charset 。これ、Encode.pm の仕様を前提にして書かれているので、指定できる文字セット名がちょっと豊富すぎますｗ。そもそもの問題として、文字セットを扱うライブラリに何を利用するのか決めないといけません (iconv にするか、nkf にするか、他のを探すか… boost にその辺やってくれるクラスがあればいいんだけどなぁ…)。

それともう一つ、#function で関数を定義するときに用いるスクリプト。 Perl 版では eval を用いる気満々で、まんま Perl で書かせるつもりでいたのですが (ファイルとかを扱えてしまえるのは問題なので、その辺の安全性をどうやって確保するかで頭を悩ませてはいましたが)、C++ から Perl パーサを呼び出す気にはなれないし (あんまり動作安定してないですからね、あれ)、自前で Perl パーサを作るなんて以ての外。という訳で、自前でスクリプト言語の仕様を考えなければなりません。まぁ、Lua かなぁ…。