• sample/EncodeString.hpp
• sample/EncodeString.cpp
• sample/regex-test.cpp

Makefile は作ってません＼(^O^)／。試してみたい人は頑張ってコンパイルしてねｗ

$ g++ -std=c++0x -o regex-test regex-test.cpp EncodeString.cpp -lboost_regex

まともな環境 (Linux + GCC4.5 とか) なら上記コマンドで通るはず。libiconv を (glibc に上書きする形で) インストールしている場合は -liconv を末尾に入れる必要があるかも。そして MinGW を使う場合は更にもう一工夫必要かも (((;/^^)/

さてこのプログラム、注目して頂きたいのは、regex-test.cpp の以下の行です。

        regex reg(u8"くま|川|(お)?魚");

正規表現を定義しているのですが、一文字でしかないはずの "お" がわざわざ丸括弧でくくってありますね。これが Perl で use utf8; していたり、 UTF-8 で JavaScript を書いていたりしているのであれば、不要な括弧です。

しかし、 Boost.Regex を UTF-8 で使用する場合には必要です。この括弧がなければ、 "?" は "お" の最終オクテットにしか適用されません。なぜなら、 Boost.Regex は UTF-8 なんて知らないので、 "お" が論理的には 1文字でしかない、なんてことは認識できないからです。

すなわち、

        regex reg(u8"くま|川|お?魚");

と書いてしまうと、"お魚" には hit しますが、 "魚" には hit しなくなってしまうのです。

otoco では、 MML コンパイラ機能において、プログラマブルマクロを定義できる機能を提供する予定です。具体的には Lua でマクロを定義し、そのマクロを用いて生成した MML をインライン展開できるようにする、といったものです (実際の所、言語に Lua を採用すべきか JavaScript を採用すべきか、はたまた Python を採用すべきかで迷っているところではあるのですが…)。

で、 (Lua を採用する場合には) 正規表現を用いた文字列加工を行う関数を提供するつもりでいるのですが (JavaScript とかだったら不要なんですけどね、言語機能にあるし)、仮に非 ASCII な文字 (列) を hit させようとする正規表現に "?" やら "[…]" やらが使われた場合、どう扱うべきなんだろう、といった辺りが悩みどころではあったりします…。

まぁなんにせよ、他に選択の余地もないので、とりあえず内部文字列は UTF-8 で実装するという方針でやっていくことにしようかと思います。前途多難じゃ… orz

1. C++0x で UCS を UTF-32 として扱う型 char32_t, u32string およびリテラル U"..." と、 libiconv の UCS-4-INTERNAL との間に互換性はあるか。
2. C++0x で新たに追加された正規表現ライブラリ <regex> は利用可能か。
3. <regex> が利用できない場合、 Boost.Regex を用いて UTF-32 文字列を処理することは可能か。

これらの調査は、すべて otoco のコアデータを扱うプログラム内で内部文字列に UTF-32 を採用することを前提としたものでした。

結論から言うと、内部文字列に UTF-32 を採用することは、現時点では諦めざるを得ない、ということになりました。＼(^O^)／ 以下、その解説です。

1 については、互換性に問題がないことを確認しました。

2 についてですが、 GCC 4.5 の標準 C++ ライブラリでは、 <regex> のヘッダファイルは存在するものの、ライブラリの実体がまだ用意されていない、という状態のようでした。

で、 3 についてなのですが… 簡単のため、以下のサンプルを見てみることにします。

#include <string>
#include <boost/regex.hpp>

using namespace std;

typedef boost::basic_regex<char32_t, boost::regex_traits<char32_t> > u32regex;
typedef boost::match_results<u32string::const_iterator> u32smatch;

int main()
{
	u32string text(U"C++0x のせかいへようこそ!!");
	u32string modified;
	u32regex reg(U"せかい");
	u32smatch match;
	while (boost::regex_search(text, match, reg)) {
		modified += match.prefix().str() + U"世界";
		text = match.suffix().str();
	}
	modified += text;
	return 0;
}

このサンプルは、期待通りに動作しても、何もしません。UTF-32 の文字列 U"C++0x のせかいへようこそ!!" の U"せかい" を U"世界" に置換する、という処理を内部で行うだけです。 u32string に対応した iostream があったとして、 UTF-32 をそのままコンソールやファイルに出しても不親切なだけなので、出力までやるなら libiconv と組み合わせるべきですが、プログラムが複雑になるので、ここではそこまで示していません (実際にはそこまで試そうとしていたのですが…)。

で、このプログラム、実際はどうなるのかというと、 GCC 4.5 でコンパイルは通るものの、実行すると、 u32regex オブジェクト (これは boost::basic_regex<char32_t, boost::regex_traits<char32_t> > のシノニムですね) のコンストラクタが std::bad_cast 例外を送出します。どうやら、 Boost.Regex は char32_t、すなわち 32bits 以上の整数型を文字コードに使用するということ、を想定した作りにはなっていなかったようなのです。よーするに char と wchar_t しか想定していなかったんですね (ん? でも GCC の wchar_t は uint32_t だったような…)。

GCC の標準 C++ ライブラリが <regex> のライブラリを実装するのを悠長に待っても居られないので、方針を転換し、内部文字列は UTF-8 で実装せざるを得なさそうです。一応、UTF-8 は文字の先頭オクテットか否かを判断するのが容易なので (0×80≦n≦0xBF 以外なら先頭オクテット)、文字境界の特定も文字数カウントも一度関数を書いてしまえば ok なのですが…。

ところが、MinGW のダウンロードサイトにて「Download Now!」と書かれたリンクボタンをクリックすると、インストーラの exe ファイルではなく、何故か zip ファイルがダウンロードされ、展開すると謎のディレクトリ構成が…。

試しに生成された bin ディレクトリ下の mingw-get.exe ファイルをダブルクリックしてみますが、一瞬コマンドプロンプトが表示されるだけで、何も行われません。こいつはいったい何なのか?

ぐぐってみたところ、MinGW ポータルの Getting Started ページに行き当たりました。どうやら、上記で落としてきたファイルを C:\MinGW ディレクトリ下に展開し、 C:\MinGW\bin ディレクトリを環境変数 PATH に追加した上で、コマンドプロンプトから

mingw-get install パッケージ名 [パッケージ名 ...]

とタイプすれば、お好みのパッケージのみをダウンロードし、よしなにインストールしてくれる、という物なのでした。 install コマンドの他、update コマンドや upgrade コマンドも用意されているので、言わば apt-get の MinGW 版、といったところでしょうか。

ただ、こいつを使ってインストールされる GCC が、 Getting Started のページでは 3.x 系であるとされていたのですが、実際には 4.5.0 がインストールされるようです (9/5 追記: すでにこの記述も 4.5 に修正されているようですね)。前回メインマシンに入れた GCC は 4.4.0 でしたが、 4.4.0 では <unorderd_map> を利用するコードをコンパイルするのに -std=gnu++0x オプションが必要であったのに対し、 4.5.0 では -std=c++0x オプションでもコンパイルできてしまったりと、早くも微妙な相違点を見つけてしまい、どっちで統一すべきか迷ってみたり…

なお、 mingw-get コマンドが知らないオプションを渡そうとした場合 (例えば、mingw-get install gcc とタイプしようとして、誤って mingw-get gcc などとタイプしてしまった場合)、深刻なエラーとやらが発生し、何故か mingw-get コマンドを実行できない状態になってしまうようです。その場合は、C:\MinGW\bin\mingw-get.exe~ ファイルを mingw-get.exe に、 C:\MinGW\libexec\mingw-get\mingw-get-0.dll~ ファイルを mingw-get-0.dll に、それぞれリネームしてあげて下さい。それで再び使えるようになるはずです。

それから、必要な追加ライブラリの類は、相変わらず手動でインストールした方が良さそうです。 libiconv をインストールしようとしたのですが、 mingw-get でインストールできるのは msys-libiconv というやつだけで、これだとどういう訳か MSYS 上ですらそのままではコンパイルできなかったりするので (コンパイル時にヘッダファイルのディレクトリとライブラリのディレクトリを指定し、実行時に DLL があるディレクトリのパスを通してやればよいのですが…面倒だし)。

今し方ダウンロードサイトを覗いてみたところ、 Inno Setup によるインストーラが復活しているようです。但し、以前までのインストーラとは若干毛色が違うようで、内部で mingw-get を利用する Web インストーラ的なものになっています。

インストーラは mingw-get-inst という名前で、現在「Download Now!」ボタンはこのインストーラにリンクしています。インストール方法は、基本的にはインストーラの exe ファイルを実行し、ひたすら Next ボタンを押し続けるだけです。但し、インストールする構成を指定する画面で、インストールしたいコンポーネントをいくつか選ぶ必要があります。

私の場合ですが、とりあえず C++ 言語は利用したいので、「C++ Compiler」にチェックを入れました。

mingw-get-inst による MinGW セットアップ(1) - C++ 言語を利用する場合

さらに、 MSYS も使いたいので、ツリーコントロールをスクロールし、一番下にある「MSYS Basic System」にもチェックを入れました。

mingw-get-inst による MinGW セットアップ(2) - MSYS を利用する場合

インストーラは mingw-get をインストールし、この mingw-get を利用して GCC や MSYS などのコンポーネントをダウンロードし、インストールしてくれるようです。ちなみに、コントロールパネルからアンインストールを行うと、 mingw-get のみが削除されるようで、 mingw-get によってインストールされたそれ以外のプログラムはそのまま残るようです。

#include <cstdint>

と書いてみたものの、これがさっぱり通らない。おおそうか、そもそも <cstdint> なんて存在しないのか、などと Twitter でつぶやいてみましたところ、ご親切な方から VC10 (Visual Studio 2010 の C/C++ コンパイラのことですね) にはありますよ、とのお返事が。

さらにもう一つ気がかりなことに、 hashmap 的なものってもう標準化されていなかったかなぁと思いつつ調べてみたところ、 C++0x であれば std::unordered_map が使えると言うことが分かったので、早速これも試してみようとテストプログラムに

#include <unordered_map>

と書いてみたところ、やっぱりこれもさっぱり通らない。で、どちらも MinGW のインストールディレクトリ以下にヘッダファイルが存在するのか検索してみると、なるほど確かにファイル自体が存在しない。

そもそも GCC は C++0x に対応しているのか? と調べてみると、軽くぐぐってみた限りでもバージョン 4.4 および 4.5 で C++0x への対応を改善したとのニュース記事が見つかるので、おそらくは 4.x 系であれば対応を進めてはいるんだろうなぁと言うことは伺えるわけです。

MinGW は割と最近導入したので、まさか古い GCC が採用されているなどとは疑いもしていなかったのですが、ここで念のためにとバージョンを確かめてみると、なんとデフォルトでインストールされている GCC のバージョンは 3.4.5 だというじゃないですか。

まさか MinGW 版の GCC が 3.4.5 で開発が止まっているなどとはさすがに思えなかったので、早速 4.x 系にバージョンアップする方法はないかと調べてみたところ、なんのことはない、 MinGW のダウンロードサイトに普通に用意されていて、それを展開して上書きインストールすれば済む話だったのでした (やり方の詳細は技術メモをご参照のこと)。

これでいよいよ <cstdint> も <unordered_map> も使える! ということで、早速以下のようなテストプログラムを書いてみました。

#include <iostream>
#include <string>
#include <unordered_map>
#include <cstdint>

int main()
{
	std::unordered_map<std::string, std::string> murachi;
	murachi["name"] = "Toshiyuki Murayama";
	murachi["handle"] = "T.MURACHI";
	murachi["age"] = "32";
	
	std::cout << "I'm " << murachi["handle"] << "(" << murachi["name"] << "), " <<
		murachi["age"] << " years old." << std::endl;
	
	std::int32_t hoge = 12345;
	std::cout << "hoge = " << hoge << std::endl;
	
	return 0;
}

これを test.cpp という名前で保存し、コンパイルを試みますが…

murachi@YUMA ~
$ g++ -o test test.cpp
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/unordered_map:35 ､ｫ､・include
､ｵ､・ｿ･ﾕ･｡･､･・・ﾂｿｽﾅ include ､ｫ､鬢ﾎﾊﾝｸ釥ｬﾍｭｱﾗ､ﾈ､ﾊ､・ﾇ､ｷ､遉ｦ:
,
                 test.cpp:3 ､ｫ､・ISO C ､ﾇ､ﾏﾌｾﾁｰ､ﾄ､ｭｲﾄﾊﾑｰ惞ﾞ･ｯ･惕ｷ､ﾞ､ｻ､・IS
O C99 ､ﾏｻﾈﾍﾑ､ｵ､・・ﾙ､ｭｻﾄ､熙ﾎ､ﾎｰ惞ﾗｵ皃ｷ､ﾞ､ｹ:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/c++0x_warning.h:31:2: error: #
error This file requires compiler and library support for the upcoming ISO C++ s
tandard, C++0x. This support is currently experimental, and must be enabled with
 the -std=c++0x or -std=gnu++0x compiler options.
test.cpp: In function 'int main()':
test.cpp:8: error: 'unordered_map' is not a member of 'std'
test.cpp:8: error: expected primary-expression before ',' token
test.cpp:8: error: expected primary-expression before '>' token
test.cpp:8: error: 'murachi' was not declared in this scope

murachi@YUMA ~
$

なんだか文字化けしたエラーが出てきてしまいました。新しいバージョンの GCC はエラーを日本語で出してくれるのか? 何はともあれ、そのすぐ後ろに GCC のオプションに関するヒントが綴られていたので、「そうか C++0x 固有の機能を利用するには -std=c++0x オプションか -std=gnu++0x オプションのどっちかを指定してあげる必要があるんだな」と気づくことができました。

で、なんとなく -std=c++0x オプションの方がまだ標準っぽい感じがしたので、それを試してみたのですが、

murachi@YUMA ~
$ g++ -std=c++0x -o test test.cpp
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/bits/pos
types.h:42,
                 from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/iosfwd:4
2,
                 from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/ios:39,
                 from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/ostream:
40,
                 from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/iostream
:40,
                 from test.cpp:1:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:159: error: '::swprintf
' has not been declared
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/cwchar:166: error: '::vswprint
f' has not been declared

murachi@YUMA ~
$

今度は <iostream> から巡り巡って参照されている <cwchar> の中で、存在しないシンボルが参照されようとしている、と怒られてしまいました。 cwchar ファイルの中も一応覗いてみましたが、これを書き換えてしまうのもよくないので、とりあえず一か八かでもう一つのオプション -std=gnu++0x を試してみることに。すると…

murachi@YUMA ~
$ g++ -std=gnu++0x -o test test.cpp

murachi@YUMA ~
$ ./test
I'm T.MURACHI(Toshiyuki Murayama), 32 years old.
hoge = 12345

murachi@YUMA ~
$

こんどはちゃんとコンパイルが通り、プログラムも期待したとおりに動作しました。

と、いうわけで、おさらいです。

• GCC のバージョンはちゃんと確認しよう。
  • 特に、C++0x 固有の機能を用いるのであれば、 GCC 4.x 以降が必要になる。
  • クロスプラットフォーム対応を前提とする場合、対応予定の全ての環境で確認し、開発に用いる GCC のバージョンをプロジェクト内で決めてしまい、それを用いるよう徹底してしまった方がよいかも…。
• GCC で <unordered_map> などの C++0x 固有の機能を用いる場合、 g++ コマンドにオプション -std=gnu++0x を付加する必要がある。
  • おそらく GCC 固有のオプションなので、 GCC 固有の機能を許可してしまっている可能性もある。 GCC 以外のコンパイラにも対応させたいのであれば、可搬性には特に注意する必要がある、かも知れない。

ちなみに、先ほどのサンプルプログラムは <unordered_map> と <cstdint> の両方をテストしていて、特に後者については以下のような記述で利用しているのですが、

	std::int32_t hoge = 12345;  // int32_t は std 名前空間に存在する

実際のところ、この記述は下記のように書き換えてもコンパイルは通ります。

	::int32_t hoge = 12345; // int32_t はグローバル名前空間にも存在する…!?

C++0x の仕様についてはまだちゃんと目を通していないので、どちらがより推奨されているのかは分かりません。この辺は後でちゃんと確認しておかねば…。

それから、そもそも C++0x には初期化リストなどの構文糖や型推論、ラムダ、Unicode 用の文字型と Unicode リテラル (UTF-32 リテラルと libiconv の UCS-4-INTERNAL って互換性あるのかなぁ…これも後で調べなきゃ…)、そしてタプルや正規表現 (std::basic_regex!!) などの追加ライブラリ群などなど…さまざまな機能の追加がなされているので、それらについても一通りさらうなり有用な書籍を探す (日本語の文献は…無いかなぁ…) なりしておかないとなぁとか思ったりするわけです (こうやってブログ記事にする為にちょっと Wikipedia に目を通してみただけでもまぁいろいろと…また実装方針を考え直さないといけない部分も結構出てきてるなぁ… ^_^;)。

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

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

これがそのサンプルプログラムです。このプログラムは、

1. 標準入力からファイルを読み込み、
2. ファイルの文字セットを自動認識し、
3. 句点「。」をピリオド「.」に、読点「、」をカンマ「,」に置換し、
4. UTF-8 に変換して標準出力に書き出す。

ということをやるものです。

で、以前のブログ記事では、

というわけで、内部コードは wchar_t のような型名で定義するのではなく、より具体的に文字セットで定義した方が良さそうだなぁという結論に至りました。候補は以下の 2通りです。

• UCS4 を内部コードとし、物理型は符号無し 32bits 整数を適当な型名に typedef して用いる。
• UTF-8 を内部コードとし、物理型は char を用いる。

と書いておりましたが、今回はこのうち、前者の UCS4 を内部コードとして用いる方法で実装しています。

とりあえず動いたから commit してみた、という段階なので、コメントが不十分だったり魔法の値が散らばっていたりと未熟なコードです。追々直していこうかと思っています。また、後者の UTF-8 を内部コードとして用いる方法についても併せて書いてみる予定です。

また、現状では boost::regex を用いたコードにはなっていないので (1文字ずつの置換なので UCS4 だと使う必要がないのよ、今のところ)、これを用いた形に修正した場合、どうなるか、といった辺りも試していきたいと思っています。実際にコードに起こしてみると、頭で分かっている以上の利点や問題点が分かってくるんじゃないかなと。

実は先日 HDD に物理的損傷らしきものを見つけてしまいまして、必要なデータだけ抜き取ってフォーマットを試みたら見事にエラーで止まりやがったのでやむなく新しいのに交換したのですよ。

ここ最近は忙しかったり体調も安定しなかったりだったので otoco の方の作業はずっと停滞してました…。やっと朝まともに起きれるぐらいに体調は戻ってきたので、そろそろ otoco の作業も復活したいなぁと思いつつ…。

ああそうだ、Linux も使えるように grub 入れ直さないと…。

個人的に気になっているのは、今 otoco でやろうとしている、楽譜情報と演奏情報 (シーケンス情報) を融合するデータ表現に関する研究が、MML なりそれ以外なりのアプローチで行われているのか、ということです。別に、既に行われているなら otoco を作るのはやめようとかそういう話ではないのですが、先行研究があれば参考にはさせて頂きたいな、とは思うわけです。

今のところそれらしい研究成果はまだ見つけられていないのですが、music macro language で検索してみたところ、面白いものを見つけました。かなり画期的な概念に基づく MML、その名も「PMML」です。

何より面白いのがスレッドという概念です。音楽においては、通常「パート」と表現される概念ですが、PMML では並列される演奏は並列される処理として表現するわけです。

例えば「名前付きスレッド」はまさにパートを表現するもので、スレッド名を定義し、そのスレッド名ごとに処理ならぬ演奏内容を分けて記述します。以下のように:

// ちなみに曲は、昔おいらが作った "Happy Mouse" でやんす
defthread(melody, string, bass)

melody {
    o=5 s frfa^crar b-rargrfr ercrdrer frar i. f s r   // フラットって "-" でいいのかしら?
}
string {
    o=4 h a b- q ^cb- h a
}
bass {
    o=3 q ff b-b- ^cc ff
}

そして名前をつけずに単にブレース { ～ } で括るとそれは無名スレッドになるのですが、無名スレッドはスコープとして利用できます。例えば上記の例で、メロディーパートは最後の音だけちょっと長い音を使っていますが、そのために音符の長さ指定が行ったり来たりしてますよね。

    // i. で付点 8分音符に変更、そして最後の休符は sで 16分音符に戻している
    o=5 s frfa^crar b-rargrfr ercrdrer frar i. f s r

ここの部分で無名スレッドによるスコープを用いると、以下のように書けるわけです。

    // 最後の音だけを付点 8分音符にする
    o=5 s frfa^crar b-rargrfr ercrdrer frar { i. f } r

スコープは、和音を表現するブラケット [ ～ ] の中で用いると、長い音と短い動く音が混じった和音を表現することも可能です。

// 動物の謝肉祭より「像」の最後の部分
defthread(tuba, p_right, p_left)

tuba {
    o=3 s { i _b- } d-rd-r { i d- } e-d-cd- cr_a-_b-cd e-fga-b-^c
    { q ^d i ^e- q _b- i c } fefrb-r e-r { q r }
}

p_right {
    o=4 s { i _b- } d-rd-r { i [ gb-^e- ] } [ b-^e-^g ] r [ b-^e-^g ] r
    [ a-^e-^a- ] r { i rr q. r }
    o=5 i r { q [ _b- { i fe- } { i a-g } ] } r [ dfa-^d ] [ e-g^e- ]
    s [ a-^c^a- ][ g^c^g ][ a-^c^a- ] r [ dfa-^d ] r [ e-g^e- ] r i rr
}

p_left {
    o=3 s { o=2 i [ _b-b- ] } [ _d-d- ] r [ _d-d- ] r { i [ gb-^e- ] } [ b-^e-g ] r [ b-^e-g ] r
    [ a-^e- ] r { i rr q. r }
    o=4 i r { q [ _b- { i fe- } { i a-g } ] } r [ dfa- ] [ e-g ]
    s [ _a-ca- ][ _gcg ][ _a-ca- ] r o=3 [ _b-b- ] r [ _e-e- ] r i rr
}

ちなみに otoco ではどう書くのかって? それは、あの、今後の宿題とさせてください (^_^;A 。

他にも、スプライン曲線的なコントロール値の変化を実現するコマンドがあったり、C言語ライクな演算子が使えたり、マクロの引数として渡す値の配列を定義できたりと、非常にプログラマブルな仕様になっています。

こういう仕様の MML はおいらもある程度は夢想したりもしたのですが、ただプログラマーにとって理想的な言語世界というのが、果たして一般的な DTM ユーザーにとっても理想的なものとなりうるのか、という点において足踏みせざるを得ません。「可読性」という言葉一つをとっても、プログラマーにとってのそれ (処理内容の理解) と、DTM ユーザーにとってのそれ (楽譜としての理解) とでは、全く意味合いが違ってくる可能性があるからです。

ただ、音楽制作に対する新たなアプローチを提供するアイデアとしては、非常に興味深いものがありますし、機能の一つ一つは非常に参考になるものがあります。いくつかのアイデアは otoco においても拝借させて頂くことがあるかも知れません。

しかし 1997年時点でこんなものが存在していたとは…。

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

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

まず文字セットですが、 UTF-16LE とはリトルエンディアンの UTF-16 エンコードのことで、 Unicode を表現するためのファイル形式です。ファイル形式であるということは、すなわちファイルに保存する方法を定めた形式であるということです。それに対して、 UCS4 はあくまで Unicode そのものであり、内部データ形式として扱えるものです。

具体的に何が違うのかというと、 UTF-16 の場合は配列内の数値 1つが必ず 1文字を表現するものであることを保証しません。実際、UTF-16 ではサロゲートペアを気にする必要があり、この処理を誤ると文字境界に破綻を来して文字化けの原因を作ってしまうことになります。これに対し、 UCS4 の場合は単に 31bits 以下の文字セットであり、それより拡張されないことが保証されています (万一拡張された場合は新たに UCS8 が規定されて包括されるのでしょうが、現実的にはあり得ないでしょう)。

私は元より Windows 畑の人なので、 wchar_t を使う場合でもサロゲートペアをどうにかすることを前提に考えていましたから、 GNU/Linux でのあり方はむしろ理想的とも思うのですが、反面内部的な処理に過ぎない部分でプラットフォーム依存を気にしながら実装しなければならないというのはあまり好ましいことではなく、そう考えると wchar_t という型は意味論的には破綻しているといわざるを得ないように思います。さらに BSD 系の UNIX 環境では wchar_t が扱う文字セットは環境のロケールに依存するなどという情報もあり… とてもじゃないですがそんなの考慮しきれるわけがありません ((((/;^^)/ 。

というわけで、内部コードは wchar_t のような型名で定義するのではなく、より具体的に文字セットで定義した方が良さそうだなぁという結論に至りました。候補は以下の 2通りです。

• UCS4 を内部コードとし、物理型は符号無し 32bits 整数を適当な型名に typedef して用いる。
• UTF-8 を内部コードとし、物理型は char を用いる。

前者のメリットは何と言っても多言語処理の確実性が高く、文字境界も気にする必要がないことです。例えば、配列の中の n個目の値は、確実に文字列の中の n個目の文字であることが保証されます。反面、 STL や Boost を用いた文字列処理においては、あらかじめ typedef された便利な型名を用いることができず、プログラム側で内部コード用に typedef したものをたくさん用意しておく必要が生じるでしょう。また、何より文字列リテラルが使えなくなるので、正規表現のハードコーディングには工夫を強いられることになります。

後者のメリットは STL の string や Boost.Regex に定義されている typedef がそのまま利用できること、そして何よりハードコーディングした文字列リテラルがそのまま利用できることです。正規表現の記述もこちらの方がよっぽどすっきりするでしょう。また、 XML の入出力を UTF-8 に限定して良いのであれば、その辺の実装も楽になるかも知れません。文字境界については注意する必要がありますが、例えば n文字目の検出は他のエンコーディングに比べれば容易であるのも UTF-8 の特徴でもあります (もちろん、UCS4 を用いる場合に比べれば、実装は複雑になりますが…)。

ちなみに、文字セットの変換にはやっぱり iconv を使うことになりそうです。 Windows 側はまだ試していないのですが… とりあえず近日中に iconv を用いた簡単なプロトタイプを書いて、上記の件も含めて検討してみる予定です…。

問題は、前回も書いた通り、 apt からインストールできる Boost のバージョンは通常で 1.34.1、最新のものを選んでも 1.37.0 になってしまう、ということです。

そこで、 otoco の開発に影響する範囲で、バージョン間にどの程度の差異があるのか、調べておくことにしました。

• Boost ライブラリ – バージョン間の差意について

とりあえず今思いつくのは正規表現まわりだけだったのでまだそこしか調べていないのですが (空文字列マッチは何気に影響範囲大きそうですが…古いバージョンで統一しておけばとりあえず問題にはならないかな…)、実際に開発が進めば利用範囲が広がり、都度気づく部分も増えていくかもしれません。上記ページはその都度更新して行く予定です。

• 技術メモ/Boostセットアップ – otoco

cl.exe コマンドを直接呼んでビルドする方法については調査完了しました。必須オプションが何気に多いですね…。実際にはあれに最適化オプションなりデバッグオプションなりがくっつくことになります。

で、今度は Ubuntu でのセットアップを調べているのですが、ここで問題発覚。どうやら Ubuntu での boost ライブラリのメインバージョンはまだ 1.34.1 で止まっているようです…。もしかしたら Debian を始め、多くの Linux ディストリビューションにおいても同様の状況なのかもしれません。当初は最新の 1.39.0 を利用する予定でしたが、事実上の汎用性が損なわれる可能性もあるので (さすがにライブラリを手動でインストールしてくれ、とやる訳にもいかないですからね…)、互換性を確認しつつ、バージョンについては考慮しなければならないかもしれません。

インストールして動かして、というあたりはまだこれから調査するところです…。