2010-04-25-01-昨日の続き

>> Site top >> weblog >> 月別アーカイブ >> 2010年04月のlog >> 2010-04-25-01-昨日の続き

最終更新日付：2010/04/25 01:00:00

昨日の続き

2010 年 04 月 25 日

さて、本題に入るとしよう。テンプレートを使用したメタプログラミングでエンディアンを操作するやつだ。

使い方から先に書くと、以下のような感じになる。

int n = LittleEndian::ConvertTo<BigEndian>( 0x12345678 );

このことからわかるのは、クラス LittleEndian にクラススコープのメンバ関数テンプレートがあり、テンプレート引数に BigEndian を渡してエンディアン変換をしているということだ。実際には、LittleEndian および BigEndian は typedef であり、以下のように定義されている。

typedef Endian<__LITTLE_ENDIAN> LittleEndian;
typedef Endian<__BIG_ENDIAN>    BigEndian;

つまり、Endian というクラステンプレートがあり、その内部にメンバ関数テンプレートとして ConvertTo() があるわけだ。で、この __LITTLE_ENDIAN と __BIG_ENDIAN とはなにか。これは、endian.h にある数値で、バイトオーダーを表現している。

#define __BIG_ENDIAN    4321
#define __LITTLE_ENDIAN 1234

ちなみに、endian.h ではマシンのバイトオーダーを __BYTE_ORDER として定義しているので、以下の定義によりマシンのエンディアンを取得できる。

typedef Endian<__BYTE_ORDER> MachineEndian;

ここまでで、Endian クラステンプレートの定義が見えてくる。以下のような感じだ。

template<int BYTEORDER>
struct Endian {
    static const int byte_order = BYTEORDER;
    template<typename ENDIAN>
    static inline int ConvertTo( int n );
};

static const int byte_order がここでのキモだ。これをコンパイラが定数として扱うことで、コンパイル時点でできる計算をかなり増やすことができる。

ここで少し脱線すると、こいつは little endian と big endian だけでなく、他のバイトオーダーも扱うことができる。例えば以下のように。

typedef Endian<3412> PDPEndian;

で、問題はメンバ関数テンプレートである ConvertTo の実装だ。これは、以下のようになる。

template<int BYTEORDER>
template<typename ENDIAN>
inline int Endian<BYTEORDER>::ConvertTo( int n ) {
    return __ConvertEndian( n, Endian<BYTEORDER>(), ENDIAN() );
};

これは、変換元と変換先の Endian クラスをタグディスパッチに使うことで、__ConvertEndian() の関数オーバーロードを使用して処理を振り分けている。このオーバーロードによって LittleEndian、BigEndian、それ以外の相互変換を個別に実装しているのだ。最初はメンバ関数テンプレート ConvertTo() 自体を特殊化しまくって対処しようと考えていたのだが、いかんせんメンバ関数自体のパラメータは int だけなので断念したような次第。

例えば、little to big の変換では、以下のような __ConvertEndian() になる。これは一番素直な変換だ。

inline int __ConvertEndian( int val, LittleEndian, BigEndian ) {
  return ( ( val & 0xFF000000 ) >> 24 ) |
         ( ( val & 0x00FF0000 ) >>  8 ) |
         ( ( val & 0x0000FF00 ) <<  8 ) |
         ( ( val & 0x000000FF ) << 24 );
};

ちなみに、変換元と変換先のバイトオーダーが等しい場合、なにもしないようにオーバーロードされている。だから例えば、MachineEndian が LittleEndian に等しいことに気付いていなくても、以下のコールは安全だ。

int n = MachineEndian::ConvertTo<LittleEndian>( 0x12345678 );

そして、もうひとつだけ例をあげておこう。little endian から little でも big でもないエンディアンに変換する場合のオーバーロードだ。

template<typename TO>
inline int __ConvertEndian( int val, LittleEndian, TO ) {
    union { int val; char ch[4]; } wk;
    wk.ch[3] = ((char*)&val)[( TO::byte_order      %10)-1];
    wk.ch[2] = ((char*)&val)[((TO::byte_order/  10)%10)-1];
    wk.ch[1] = ((char*)&val)[((TO::byte_order/ 100)%10)-1];
    wk.ch[0] = ((char*)&val)[((TO::byte_order/1000)%10)-1];
    return wk.val;
};

なんだか複雑そうに見えるが、重要なのは変換対象である val 以外は全て定数ということだ。つまり、これは計算のほとんどをコンパイル時点でやってしまえる。昨日試した限りでは、配列解釈による転置よりもビットシフトで実装する方が速いが、このような変換でも同じように実装することが可能だろう。

ひとまずこんなところだが、冷静に考えるとまだまだ改善の余地があるような気がしてくる。全てをビットシフトでなんとかでき、計算の多くをコンパイル時点にやってしまえるなら、ConvertTo からタグディスパッチを使って __ConvertEndian のたくさんのオーバーロードの中から処理を選ぶ必要などないのかもしれない。そこのところを上手く書くことができれば、同じ効率でも実装はもっと短くなる。

　

コメント

いなあも - 04/25/2010 09:25:46 PM

kagelow - 04/25/2010 09:42:03 PM

いなあも - 04/26/2010 02:06:59 AM

sinray - 04/29/2010 09:47:44 PM

このページにコメントする

　

このページのタグ

Page tag : 開発

　

　

---

Copyright(C) 2005-2018 project-enigma.
Generated by CL-PREFAB.