このエントリは、C++11 Advent Calendar 2011 への参加記事です。
初心者表明を免罪符にするつもりは毛頭無いのですが、 C++0x/11 の学習、およびそれを用いた経験はまだまだ浅いため、内容的に拙い部分が多々あることを、あらかじめご容赦願いたいと思います m(_ _)m 。ていうか突っ込みだいかんげいでつ。
一応 ISO/IEC 14882:2011 の draft “n3242″ を参照しています。 GCC は 4.7 入れるの面倒だったので、動作確認できるものについては Ubuntu 11.10 に入っていた 4.6.1 を用いています。
文字リテラルについてはドラフトの 2.14.3、文字列リテラルについては 2.14.5 に記述があります。
(さらに…)
ご無沙汰ぶりです…。
以前、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 かなぁ…。