そのような場合、 C++11 であれば、 <type_traits> を利用します。

以下は、整数の型を要素に持つ任意のコンテナを受け取り、その全要素の合計を返す関数 calcSum() の実装例です。

#include <iostream>
#include <type_traits>
#include <array>
#include <set>

extern void * enabler;

template <typename cont_t, typename value_type = typename cont_t::value_type,
    typename std::enable_if<std::is_integral<typename cont_t::value_type>::value>::type *& = enabler>
value_type calcSum(cont_t const& container)
{
    value_type sum = 0;
    for (auto n : container)
        sum += n;
    return sum;
}

int main()
{
    std::array<int, 5> primes = { 2, 3, 5, 7, 11 };
    for (int i = 0; i < primes.size(); i++)
        std::cout << (i == 0 ? "" : " + ") << primes[i];
    std::cout << " = " << calcSum(primes) << std::endl;
    
    // std::array<double, 5> floating_nums = { 1.414, 1.732, 2.236, 2.718, 3.142 };
    // auto result = calcSum(floating_nums);    // エラー: そんな関数無いよ
    
    std::multiset<short> nums = { 152, 24, 73, -15, 250, 3, 24 };
    bool is_first = true;
    for (auto num : nums) {
        std::cout << (is_first ? "" : " + ") << num;
        is_first = false;
    }
    std::cout << " = " << calcSum(nums) << std::endl;
    
    return 0;
}

実行結果は以下の通りです。

2 + 3 + 5 + 7 + 11 = 28
-15 + 3 + 24 + 24 + 73 + 152 + 250 = 511

Boost ライブラリを含む C++ 全般の話題を追い続けてきた人であれば当然ご存じの知識だと思います。ええ、そうです、今回は完全に自分用のメモです (汗。こういう書き方があること自体は認識していたのですが、いやー、やっぱり実際に使わないことには身につかないですね (^_^;A 。

基本的には、テンプレートの中で、制限したい通りの条件に適合する場合のみ true になるような定数式を std::enable_if< ～ > で括ってやり、そのクラスメンバである型 type を typename として評価する、というものです。この std::enable_if<foobar>::type は、 foobar が true になる場合のみ (テンプレートの特殊化によって) 定義されるような仕組みになっていて、これが false になってしまう (すなわち、あなたの指定したい条件に合致しない) 呼び出し方をしようとすると、単にオーバーロードできないケースとして無視されます。

上記のケースでは要素が整数型以外の場合はオーバーロード可能な関数が存在しないものとしてコンパイルエラーになりますが、別途浮動小数点用の実装や std::complex<T> 用の実装、さらには std::string 用の実装なんかも用意してあげることで、それぞれに独自の処理を実現させるということもできちゃう、という寸法です。便利。

さて、前回の記事でお見せした、 iconv のラッパークラスをテンプレートクラスに作り直す際、 <unorderd_map> を利用していて気づいたことの備忘録です。

• EncodeString.hpp
• EncodeString.cpp

問題

テンプレート引数に、内部文字列の (アラインメントを決定する) 物理型と文字セットを指定できるようにしたかったのですが、文字セットを示す文字列そのものをテンプレート引数に渡すことはできないので、代わりに文字セットを表す列挙値を定義し、対応する「文字セットを表す文字列」と関連づけた連想配列を <unorderd_map> を用いて用意する、ということをやってみることにしました。 C/C++ の列挙値は int にキャスト可能なので昔の自分だったら単純に「文字セットを表す文字列」の配列を用意して添え字代わりに列挙値を突っ込むところですが、メンテナンス性良くないですし、ハッシュテーブルなら検索コストは (ほぼ) 変わらないですからね。

で、ヘッダファイルの方で列挙型を定義しーの、

enum charset_t {
    chset_Utf8, chset_C99, chset_Java,
    chset_Ucs2, chset_Ucs2Be, chset_Ucs2Le,
    chset_Ucs4, chset_Ucs4Be, chset_Ucs4Le,
    chset_Utf16, chset_Utf16Be, chset_Utf16Le,
    chset_Utf32, chset_Utf32Be, chset_Utf32Le,
    chset_Utf7,
    chset_EucJp, chset_EucJis0213,
    chset_Iso2022Jp, chset_Iso2022Jp2, chset_Iso2022Jp1, chset_Iso2022Jp3,
    chset_ShiftJis, chset_Cp932, chset_ShiftJisX0213,
};

テンプレート化しない実装部分のクラスに static で const な連想配列メンバを追加しーの、

class EncodeStringImpl
{
    typedef std::unordered_map<charset_t, char const *> cnmap_t;
    static cnmap_t const CharsetNames;

    // ...
};

実装ファイルの方で連想配列の値を定義しーの、

EncodeStringImpl::cnmap_t const EncodeStringImpl::CharsetNames = {
    { chset_Utf8, "UTF-8" }, { chset_C99, "C99" }, { chset_Java, "JAVA" },
    { chset_Ucs2, "UCS-2" }, { chset_Ucs2Be, "UCS-2BE" }, { chset_Ucs2Le, "UCS-2LE" },
    { chset_Ucs4, "UCS-4" }, { chset_Ucs4Be, "UCS-4BE" }, { chset_Ucs4Le, "UCS-4LE" },
    { chset_Utf16, "UTF-16" }, { chset_Utf16Be, "UTF-16BE" }, { chset_Utf16Le, "UTF-16LE" },
    { chset_Utf32, "UTF-32" }, { chset_Utf32Be, "UTF-32BE" }, { chset_Utf32Le, "UTF-32LE" },
    { chset_Utf7, "UTF-7" },
    { chset_EucJp, "EUC-JP" }, { chset_EucJis0213, "EUC-JISX0213" },
    { chset_Iso2022Jp, "ISO-2022-JP" }, { chset_Iso2022Jp2, "ISO-2022-JP2" },
    { chset_Iso2022Jp1, "ISO-2022-JP1" }, { chset_Iso2022Jp3, "ISO-2022-JP3" },
    { chset_ShiftJis, "SHIFT_JIS" }, { chset_Cp932, "CP932" }, { chset_ShiftJisX0213, "SHIFT_JISX0213" },
};

実際に使いーの、とやってみたはよいのですが、

void EncodeStringImpl::encode(void const *src, size_t src_length, size_t chr_size, charset_t from_charset,
    charset_t to_charset)
{

    // ...

    class auto_iconv_t {    // 生成時に iconv_open してスコープ抜ける時に iconv_close するプライベートクラス…
        const iconv_t impl;
    public:
        auto_iconv_t(charset_t from_cs, charset_t to_cs) :
            // ↓こことか
            impl(iconv_open(CharsetNames.find(to_cs)->second, CharsetNames.find(from_cs)->second))
        {
            if (impl == reinterpret_cast<iconv_t>(-1)) {
                // ↓こことか
                throw EncodeStringException(string("LIBICONV initialize error: please check character set name \"") +
                    CharsetNames.find(from_cs)->second + "\"(from) or \"" + CharsetNames.find(to_cs)->second +
                    "\"(to)");
            }
        }
        ~auto_iconv_t() { iconv_close(impl); }
        iconv_t get() const { return impl; }
    } iconv_handle(from_charset, to_charset);

いざ g++ してみると、「std::hash<charset_t>::operator()(charset_t) const なんて定義されてねーよ」とリンカ様に怒られてしまいました。

murachi@ubuntu-vbox:~/otoco/trunk/sample$ g++ -std=c++0x -o kumapan EncodeString.cpp kumapan.cpp 
/tmp/ccIn30PX.o: In function `std::__detail::_Hash_code_base<charset_t, std::pair<charset_t const, char const*>, std::_Select1st<std::pair<charset_t const, char const*> >, std::equal_to<charset_t>, std::hash<charset_t>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, false>::_M_hash_code(charset_t const&) const':
EncodeString.cpp:(.text._ZNKSt8__detail15_Hash_code_baseI9charset_tSt4pairIKS1_PKcESt10_Select1stIS6_ESt8equal_toIS1_ESt4hashIS1_ENS_18_Mod_range_hashingENS_20_Default_ranged_hashELb0EE12_M_hash_codeERS3_[std::__detail::_Hash_code_base<charset_t, std::pair<charset_t const, char const*>, std::_Select1st<std::pair<charset_t const, char const*> >, std::equal_to<charset_t>, std::hash<charset_t>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, false>::_M_hash_code(charset_t const&) const]+0x19): undefined reference to `std::hash<charset_t>::operator()(charset_t) const'
/tmp/ccIn30PX.o: In function `std::__detail::_Hash_code_base<charset_t, std::pair<charset_t const, char const*>, std::_Select1st<std::pair<charset_t const, char const*> >, std::equal_to<charset_t>, std::hash<charset_t>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, false>::_M_bucket_index(std::__detail::_Hash_node<std::pair<charset_t const, char const*>, false> const*, unsigned int) const':
EncodeString.cpp:(.text._ZNKSt8__detail15_Hash_code_baseI9charset_tSt4pairIKS1_PKcESt10_Select1stIS6_ESt8equal_toIS1_ESt4hashIS1_ENS_18_Mod_range_hashingENS_20_Default_ranged_hashELb0EE15_M_bucket_indexEPKNS_10_Hash_nodeIS6_Lb0EEEj[std::__detail::_Hash_code_base<charset_t, std::pair<charset_t const, char const*>, std::_Select1st<std::pair<charset_t const, char const*> >, std::equal_to<charset_t>, std::hash<charset_t>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, false>::_M_bucket_index(std::__detail::_Hash_node<std::pair<charset_t const, char const*>, false> const*, unsigned int) const]+0x28): undefined reference to `std::hash<charset_t>::operator()(charset_t) const'
collect2: ld はステータス 1 で終了しました
murachi@ubuntu-vbox:~/otoco/trunk/sample$ 

解決策

ヘッダーファイルの方で、以下の記述を列挙型の定義のすぐ後辺りに追加してやることで、リンクも通るようになります。テンプレートの特殊化ってやつですね。

namespace std {
template <>
    inline size_t
    hash<charset_t>::operator()(charset_t val) const
{
    return static_cast<size_t>(val);
}
}

解説

std::hash テンプレートクラスの実装は、 libstdc++ の場合、ヘッダファイルが置かれる然るべきディレクトリ配下の bits/functional_hash.h に記述されています。ここでは、非ポインタ型 T に対する operator() は (宣言はされているものの) 定義されていません。

  /// Primary class template hash.
  template<typename _Tp>
    struct hash : public __hash_base<size_t, _Tp>
    {
      size_t
      operator()(_Tp __val) const;
    };

  /// Partial specializations for pointer types.
  template<typename _Tp>
    struct hash<_Tp*> : public __hash_base<size_t, _Tp*>
    {
      size_t
      operator()(_Tp* __p) const
      { return reinterpret_cast<size_t>(__p); }
    };

で、この operator() の実装は、ごくごく基本的な組み込み型に対してのみ特殊化されています (ここは流石に長くなるので引用しませんが…)。

こうした実装は C++11 のドラフトにも明記されている標準の仕様に則ったものです。「20.8.12 Class template hash」に以下のような記述があります。

1. The unordered associative containers defined in 23.5 use specializations of the class template hash as the default hash function. For all object types Key for which there exists a specialization hash<Key>, the instantiation hash<Key> shall:
   • satisfy the Hash requirements (17.6.3.4), with Key as the function call argument type, the DefaultConstructible requirements (Table 19), the CopyAssignable requirements (Table 23),
   • be swappable (17.6.3.2) for lvalues,
   • provide two nested types result_type and argument_type which shall be synonyms for size_t and Key, respectively,
   • satisfy the requirement that if k1 == k2 is true, h(k1) == h(k2) is also true, where h is an object of type hash<Key> and k1 and k2 are objects of type Key.

   template <> struct hash<bool>;
   template <> struct hash<char>;
   template <> struct hash<signed char>;
   template <> struct hash<unsigned char>;
   template <> struct hash<char16_t>;
   template <> struct hash<char32_t>;
   template <> struct hash<wchar_t>;
   template <> struct hash<short>;
   template <> struct hash<unsigned short>;
   template <> struct hash<int>;
   template <> struct hash<unsigned int>;
   template <> struct hash<long>;
   template <> struct hash<unsigned long>;
   template <> struct hash<long long>;
   template <> struct hash<unsigned long long>;
   template <> struct hash<float>;
   template <> struct hash<double>;
   template <> struct hash<long double>;
   template <class T> struct hash<T*>;
   

そんな訳で、デフォルトで std::hash を利用する std::unordered_map を enum 型をキーにして使用したい場合には、その enum 型で std::hash::operator() を特殊化してあげる必要があるのです。

初心者表明を免罪符にするつもりは毛頭無いのですが、 C++0x/11 の学習、およびそれを用いた経験はまだまだ浅いため、内容的に拙い部分が多々あることを、あらかじめご容赦願いたいと思います m(_ _)m 。ていうか突っ込みだいかんげいでつ。

一応 ISO/IEC 14882:2011 の draft “n3242″ を参照しています。 GCC は 4.7 入れるの面倒だったので、動作確認できるものについては Ubuntu 11.10 に入っていた 4.6.1 を用いています。

Unicode に対応したリテラル

文字リテラルについてはドラフトの 2.14.3、文字列リテラルについては 2.14.5 に記述があります。

文字リテラルには従来の

'a'
L'あ'

といったスタイルに加えて、

u'\u00a9'   // コピーライト記号
U'\U0002000b'  // 丈の右上に点がついた字

といったスタイルが追加されました。想定されるべき対応関係を表にすると以下の通りになります。

文字列リテラルではさらに u8 という接頭子も使えます。

u8"Copyright \u00a9 2011 Harapeko, Inc."    // \u00a9 は UTF-8 のオクテット列 [C2 A9] に変換される
u"\U0002000bは「丈」の字にクリソツ"         // \U0002000b は UTF-16 の該当するサロゲートペアに変換される…ハズ

対応関係の表は、…面倒くさいからもういいか。

あとさらっと流しちゃいましたが、 Unicode 用のエスケープ文字も追加されました。\uNNNN は 16bits の、 \UNNNNNNNN は 32bits の UCS を表現できます。上記の例のように、適切な文字列リテラル内で使用すれば、対応する文字セットの数値列に適宜変換されるはずです。この辺の説明はドラフトの 2.3 にありますが、以下の説明の通り、あくまで UCS の文字値を表現するものであって UTF の数値列を表現するものではないので、 \uNNNN の形式でサロゲートペアの上位代用符号位置に相当する値を指定することはできません。

The character designated by the universal-character-name \UNNNNNNNN is that character whose character
short name in ISO/IEC 10646 is NNNNNNNN; the character designated by the universal-character-name \uNNNN
is that character whose character short name in ISO/IEC 10646 is 0000NNNN. If the hexadecimal value for a
universal-character-name corresponds to a surrogate code point (in the range 0xD800.0xDFFF, inclusive),
the program is ill-formed. Additionally, if the hexadecimal value for a universal-character-name outside the
c-char-sequence, s-char-sequence, or r-char-sequence of a character or string literal corresponds to a control
character (in either of the ranges 0×00.0x1F or 0x7F.0x9F, both inclusive) or to a character in the basic
source character set, the program is ill-formed.15

Unicode に対応した物理型

Unicode に対応した型については、ドラフトの 3.9.1 に説明があります。重要なのは多分以下の箇所。

5. Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest
   extended character set specified among the supported locales (22.3.1). Type wchar_t shall have the same
   size, signedness, and alignment requirements (3.11) as one of the other integral types, called its underlying
   type. Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as
   uint_least16_t and uint_least32_t, respectively, in <stdint.h>, called the underlying types.

エーゴは苦手なんですが、ここを読む限り、wchar_t はサポートするロケールに含まれるもっとも大きな値の文字値を表現できるのに十分なサイズの整数型であることが補償されてなきゃいけなさそうに見えます。 wchar_t については大分昔に見捨てているんですが (^_^; 、VC++2010 だと 32bits 整数に変更されていたりするんでしょうか…?

# この辺とか見る限り、やっぱり unsigned short int 相当、のままみたいですね… orz

char16_t と char32_t は、それぞれ UTF-16、 UTF-32 を扱うための型と考えて差し支えなさそうです。

「内部文字」のポリシー

型についての想定を考えるならば、プログラムが内部で扱う文字データは、 C++11 では wchar_t を使用するべきであるように思われます。将来的にはそうなってゆくべきなのでしょう。しかし過去との互換性などの観点から、各ベンダーの wchar_t に対する取り扱いは当面現状維持か、もしくは段階的な仕様変更 (コンパイラオプションでの切り替え等) となっていくことが予想されます。

それに対し、 UTF-32 に関して言えば、恐らく向こう十何年かぐらいは「1要素 = UCS 1文字」であり続けるのではないかと思われます。従って、内部文字への要件として「1文字を 1つの数値のみで扱いたい」というのがあるのであれば、当面は char32_t と U"…" 形式のリテラルを用いるのが良さそうです。

char32_t で文字列置換を試してみる

そんなわけで、実際に UTF-32 を内部文字の文字セットとして採用したプログラム例を作ってみることにしました。内容的には、静的に用意した文字列内のすべての「くま」を「ぱんだ」に置き換える、という簡単なものです。

#include <iostream>
#include <algorithm>
#include <string>

using namespace std;

int main()
{
    u32string before = U"てくまくまやこんてくまくまやこん むらやましゃちょうよ おおきなくまにな～ぁれ";
    u32string after;
    u32string kuma = U"くま";
    u32string panda = U"ぱんだ";

    auto start_it = before.begin();
    auto find_it = start_it + (kuma.size() - 1);
    while (find_it < before.end()) {
        int cnt = 0;
        auto stop_it = find_if(kuma.rbegin(), kuma.rend(), [&cnt, find_it](char32_t letter) {
            return *(find_it - cnt++) != letter;
        });
        if (stop_it != kuma.rend()) {
            find_it += cnt;
            continue;
        }
        // くまを発見、ぱんだに変身!!
        after.append(start_it, find_it - (kuma.size() - 1));
        after += panda;
        start_it = find_it + 1;
        find_it = start_it + (kuma.size() - 1);
    }
    after.append(start_it, find_it);

    cout << "before: " << before.size() << endl;
    cout << "after: " << after.size() << endl;

    return 0;
}

えっと… アルゴリズムの説明とかはいいですよね? 文字列の先頭からと検索語の後からで評価して、完全一致しなかった場合は一致した数値の数だけ読み飛ばして、を繰り返すというオーソドックスなやり方です。これだったらかっこつけて find_if とか使わんで for で回しても大して変わらんやんとかそういう突っ込みはさておき (^_^; 。

GCC4.6/Ubuntu での実行結果は以下の通り。

murachi@ubuntu-vbox:~/otoco/trunk/sample$ g++ -std=c++0x -o kumapan-n kumapan-n.cpp 
murachi@ubuntu-vbox:~/otoco/trunk/sample$ ./kumapan-n
before: 39
after: 44
murachi@ubuntu-vbox:~/otoco/trunk/sample$ 

実行結果として置換前後の u32string::size() を表示しています。 5つある「くま」が「ぱんだ」に置き換えられたので、その数が 5 増えています。増える筈の文字数と一致するので、正しく動作しているように見えます。

iconv を使って実際に出力してみる

さて、実際の文字列を出力してみたいのですが、このままだとロケールが UTF-8 で動作している端末上では表示できません。ファイルに出力してテキストエディタで、という手もありますが、せっかくなので libiconv を使って指定した文字セットに変換して出力、ということをやってみることにしましょう。

libiconv の利用に際しては、お手製のラッパークラスを作成することで対応しました。作成したソースコードを以下にリンクします。

• EncodeString.hpp
• EncodeString.cpp

このクラスは過去の記事においても使用しておりますが、 C++11 の勉強も兼ねて (?)、内部文字に使用する物理型と文字セットをテンプレートパラメータに指定できるテンプレートクラスに書き換えています (あ、過去の記事でのソースへのリンク先が最新版になっちゃってる…直さなきゃ…)。

そして先ほどのサンプルプログラムは、最初の方で EncodeString.hpp を #include し、

#include <iostream>
#include <algorithm>
#include <string>

#include "EncodeString.hpp" // ←

using namespace std;

最後の方で出力内容を以下のように修正します。

    cout << "before: " << EncodeString<char32_t, chset_Utf32>(before, chset_Utf8).getCharArray() << endl;
    cout << "after: " << EncodeString<char32_t, chset_Utf32>(after, chset_Utf8).getCharArray() << endl;

Windows 環境とかで Shift JIS (CP-932) で出力したい人は、 chset_Utf8 を chset_Cp932 に置き換えてあげれば ok です。GCC4.6/Ubuntu での実行結果は以下の通り。

murachi@ubuntu-vbox:~/otoco/trunk/sample$ g++ -std=c++0x -o kumapan EncodeString.cpp kumapan.cpp 
murachi@ubuntu-vbox:~/otoco/trunk/sample$ ./kumapan
before: てくまくまやこんてくまくまやこん むらやましゃちょうよ おおきなくまにな～ぁれ
after: てぱんだぱんだやこんてぱんだぱんだやこん むらやましゃちょうよ おおきなぱんだにな～ぁれ
murachi@ubuntu-vbox:~/otoco/trunk/sample$ 

環境によっては libiconv を別途導入してコンパイルオプションに -liconv を付け加える必要があるかもしれません (MinGW とか←動作未確認)。

正規表現を使いたい

さて、上記のサンプルでさらっと u32string とか使っちゃってますが、このシノニムはドラフトの 21.3 にてちゃんと明記された標準のものです。もちろん、 u16string というのも存在します (u8string は無いので、考慮されているのはアラインメントのみと考えるべきですが…)。

しかし、「28 Regular expressions library」の章においては、 char32_t という文字はカケラも hit しません。標準の <regex> においては、 char16_t、 char32_t への対応は見送られてしまっているようです。

もちろん、basic_regex はテンプレートクラスなのですから、自分でテンプレートパラメータを指定してあげればうまくいきそうに見えます。しかし、同様の試みを Boost.Regex について行った際には、 std::bad_cast 例外が送出されてプログラムがエラー終了してしまいました。将来的には、あるいは処理系によってはうまく動かせる (ようになる) のかもしれませんが、あまり期待は持たない方が良いかもしれません…。

# そもそも GCC (libstdc++) では <regex> 自体がまだちゃんと実装されてなかったり… orz

もっとも、Boost.Regex の ICU 拡張における UChar32 と char32_t (およびそれらの配列へのポインタ) を無理矢理キャストして使うと割と上手く行くっぽかったりするので、どうにかこうにかラッパーを書いて当座はそれで凌ぐというのも手かもしれません…。

ちなみに、char と UTF-8 を使用するのであれば <regex> はそのまま使えるはずですが、その場合、 (Boost.Regex と同様に) <regex> は UTF-8 を知らないので、マルチバイト特有の問題に悩まされることになるでしょう。少なくとも日本語の文字に対する量指定子 (あ+ とか あ? とか) は期待通りには動きません。

仮に、<regex> が char32_t で利用できる場合、先のサンプルは以下のようなコーディングになるでしょう。こういう風に組める日がいつか来るといいですね… (;_;)/。

#include <iostream>
#include <algorithm>
#include <string>
#include <regex>

#include "EncodeString.hpp"

using namespace std;

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


int main()
{
    u32string before = U"てくまくまやこんてくまくまやこん むらやましゃちょうよ おおきなくまにな～ぁれ";
    u32string after;
    u32regex reg(U"くま");
    u32smatch match;

    u32string textbuf = before;
    while (regex_search(textbuf, match, reg)) {
        after += match.prefix().str() + U"ぱんだ";
        textbuf = match.suffix().str();
    }
    after += textbuf;

    cout << "before: " << EncodeString<char32_t, chset_Utf32>(before, chset_Utf8).getCharArray() << endl;
    cout << "after: " << EncodeString<char32_t, chset_Utf32>(after, chset_Utf8).getCharArray() << endl;

    return 0;
}

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

using namespace std;

using boost::u32regex;
using boost::u32match;

int main()
{
        u32string text(U"C++0x のせかいへようこそ!!");
        cout << "pre-modified text length = " << text.length() << endl;
        u32string modified;
        u32regex reg(reinterpret_cast<UChar32 const*>(U"せかい"));
        u32match match;
        while (boost::regex_search(reinterpret_cast<UChar32 const*>(text.c_str()), match, reg)) {
                modified += u32string(reinterpret_cast<char32_t const*>(match.prefix().str().c_str())) + U"世界";
                text = reinterpret_cast<char32_t const*>(match.suffix().str().c_str());
        }
        modified += text;
        cout << "modified text length = " << modified.length() << endl;
        return 0;
}

とりあえず動作確認環境は以下の通りです。

• Ubuntu 11.04 + gcc 4.5.2 + Boost 1.42.0
• Ubuntu 10.04 LTS + gcc 4.4.3 + Boost 1.40.0

どちらでもコンパイルコマンドは以下で通ります (ソースファイルを u32test.cpp として保存した場合)。

$ g++ -std=c++0x -o u32test u32test.cpp -lboost_regex

実行してみると、置換前と置換後の文字数が正しくカウントされており、マッチングが期待通りに動作していることが確認できます。

$ ./u32test
pre-modified text length = 17
modified text length = 16
$ 

ただ、コードを見ていただければわかる通り、 reinterpret_cast の嵐であり、こうした書き方が C++0x 的にも Boost.Regex 的にも ICU 的にも Valid なのかはわかりません。また、現時点では Windows 環境 (MinGW + gcc 4.5 など) での動作確認は行っておりません。 ICU 拡張部分のヘッダを見る限り、内部で wchar_t を使っているので、 wchar_t が 16bits 境界になっている Windows では、バイトオーダーがひっくり返るなどの問題があって、もしかしたら正常に動かないかもしれません。

あくまで参考までと言いますか、将来的にはこういう感じの書き方ができるようになると良いなぁと言う程度の妄想、と捉えていただければと思います… m(_ _)m

ちなみに、ここ最近ちっとも進んでいない otoco ですが、恐らく C++0x 自体の採用を見送る形になると思われます…。ただ、 Boost.Regex の ICU 拡張は有効利用できそうな気がしてきたので、こちらは利用することになるかもしれません。

Google の re2 に流れてしまいそうな悪寒もしてますが…。

今回も必死こいてメモ執りましたよ。終盤力尽きたけど orz

• Boost.勉強会 #4 ノート

しかしさすがにこの年で一日通しはキツいっすなぁ…。

• 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 なのですが…。

実に楽しいイベントでした。 5時間ほぼぶっ通しだったのでさすがにくたびれましたが… (^_^;A

自分なりにメモしたノートを公開していますので、よかったら復習にご活用ください。かなり荒いメモですが…。

そういえば sexyhook2 の話で Win32 API をフックするのに DLL を読み込んだプログラム領域を直接書き換えているんだけどそれって大丈夫なんだっけ? という話題が出て、昔、 3D CAD モックアップツールのプロセスを生成してからデバッグアタッチし、そのプロセスが読み込んでいる SwapBuffers() API や wglSwapLayerBuffers() API の先頭アドレスをブレークポイント命令に置き換えて、 WaitForDebugEvent() API がブレークポイントを拾ってくる時間あたりの回数をカウントすることで、そのモックアップツールの 3D 処理をベンチマークするツールを (仕事で!) 作ったことがあるおいらとしては、そのときは「まぁ、大丈夫なんでねぇの?」とか思いつつ特に何もコメントしなかったのですが、後になってなんとなーく、そういえばその辺の扱いって NT 系と 9x 系とでは違ってたよーな…とか思い返したりしたわけですが、はっきり言ってうろ覚えなのでなんとも言えんのです。一応調べて rti さんに伝えておいた方がいいかな…そもそも 9x 系に対応するのかどうかは別として。

しかしこの手の講習会は当方初参戦だったのですが、とても刺激になります。周り若い人ばっかりだし…。今後もいろいろと参加したいです。

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