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 に目を通してみただけでもまぁいろいろと…また実装方針を考え直さないといけない部分も結構出てきてるなぁ… ^_^;)。