今回は割と初歩的な内容になります。あと、記事中のコードはテストしてないので動作を保証できません。

方法1. 普通にキャストする

DataTable table = view.Select();
foreach (var row in table)
{
    var seq = (int)row["HOGE_CD"];
    var name = (string)row["HOGE_NAME"];

    var remark = row["HOGE_REMARK"].GetType() == typeof(string) ?
        (string)row["HOGE_REMARK"] : null;

    // 処理 ...

}

NULL を許容するフィールドについては型チェックを行う必要がある、というのがポイントになります。 NULL 値は null ではなく DBNull.Value として入ってくるので、そのままキャストしようとすると InvalidCastException 例外 が送出される場合があるからです。

方法2. as 演算子を使う

DataTable table = view.Select();
foreach (var row in table)
{
    var seq = row["HOGE_CD"] as int?;
    var name = row["HOGE_NAME"] as string;
    var remark = row["HOGE_REMARK"] as string;

    // 処理 ...

}

as 演算子は、型キャストが可能ならばキャストを行い、不可能な場合は null を返すという、最近ありがちなフレームワークでの頻繁に down cast を要求するような実装においては非常に便利な演算子です。 C++ で言うところの dynamic_cast 演算子に似ています (なので、個人的にはなるべく避けたい、頼り切りたくない概念なのですが…)。

普通に型キャストを行う方法に比べると、 NULL 許容フィールドに対しても同じように書けるため、非常にすっきりします。しかし、 int のような据え置き型などの、 null を許容しない型 (.NET では構造体と呼ばれているもの) に対して使うことは出来ません。その為、 int 型の値を取得する際には、指定する型を int? 型としているのがポイントです。これは、以下のように書くのと同じ意味になります。

    var seq = row["HOGE_CD"] as Nullable<int>;

Nullable<T> 構造体は null を許容する特殊な構造体という位置づけで、通常の値型の値と同じように四則演算や比較演算を行うことも出来たりします。但し、元の値型が要求される場面ではそのまま渡すことは出来ないので、 null チェックをしてから Value プロパティを使う必要があります。

    if (seq.HasValue)   // null ではないことを確認
        MyMethod(seq.Value, name, remark);
    else
    {
        // nul だった場合の処理 ...
    }

方法3. object.ToString() メソッドを使う

DBNull.ToString() が常に string.Empty を返すことを逆手にとり、元の値の型に関係なく手当たり次第に ToString() を呼んでしまえという考え方もあったりします。そのまま文字列で出力することの多い ASP.NET での開発などでは割とよく見かける手法です。

DataTable table = view.Select();
foreach (var row in table)
{
    var seq = row["HOGE_CD"].ToString();
    var name = row["HOGE_NAME"].ToString();
    var remark = row["HOGE_REMARK"].ToString();

    // 処理 ...

}

数値が入るフィールドの値をそのまま文字列として出力したいようなケースでは便利です。但し、 DateTime 型のように、そのまま ToString() してしまうと必ずしも期待した通りの表示にならないものもあるので、注意が必要です。

文字列型のフィールドの場合、単に出力する用途であれば null が許容されるケースが殆どなので (文字列連結演算でも null の混在は許容されています)、 as 演算子を用いる方法の方が適切かも知れません。そうでない場合は、それこそ NULL 値をチェックして分岐するようなコーディングが必要なことが殆どであるハズなので、やはり as 演算子を用いる方法の方が適切であるといえます。

方法4. object 型のまま用いる

ToString() メソッドの利用にも通じるのですが、 例えば値の比較にのみ用いるので object.Equal() メソッドを呼べばいいか、みたいな使い方もあり得ます。

DataTable table = view.Select();
foreach (var row in table)
{
    // ...

    // 特定のステータスのレコードに対してのみ、何か特別な処理をさせたい場合など
    if (row["HOGE_STATUS"].Equal(MyConstant.HogeStatus.SpecialState))
    {
        // 処理...
    }
}

あるいは、そもそも object 型の値を要求するようなメソッドやプロパティに渡して用いるようなケースでは、わざわざ型キャストしてやる必要もないでしょう。 StringBuilder を用いて値を連結して使う場合なんかもそうですね。

まとめ

どの方法にもそれぞれ利点はあるので、ケースバイケースで使い分けると良いのではないかと思います。指針としてはこんな感じになるでしょうか。

そのような場合、 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;
}