enable_ifが使えて助かったー、と思ったんだが、long longに対応しなきゃならなくなった。やべえ。
　type traitsには型のサイズとか見当たらないよな…。むーん。boost::mplには無いんかな。あった。sizeof_とかいう怪しげな物が。つーか何もかも全部が怪しげだ（笑）。
　じゃ試しに判別用の関数を書くか。いやメタ関数か。

template <typename T>
struct is_64bit : mpl::equal_to< mpl::sizeof_<T>, mpl::size_t<8> > {};
template <typename T>
struct is_signed_64bit : mpl::and_< is_signed<T>, is_64bit<T> > {};

　さあ、どんどん変な呪文っぽくなってきました。
　どうせだからint8_tからuint64_tまで全部書いちゃおうぜー。で、unionのテンプレートメンバ関数で全部enable_ifで中身書き分けて、と…。

　いや、完成はしたし、一見ちゃんと動いてるんですが。こういう時って大抵何か間違ってる気がするんだよなあ。妙に力が入ってる感じっつーか。視点を変えるともっとお気楽な手法で終わることが多い。まあ例外もあるけど。
　でも、Boostも標準ライブラリもintrinsicsも無いとしたら、現状の他のコードも色々と変な呪文の塊になりそうだしなあ…。こんなもんなのかも。
　まあ、一人でやるコードだから黒魔術でも何でもいいんだけど。むしろ、似たようなコードのコピペが大量に発生したんで気持ち悪い、つー話かも。でもunionで型変換避けるとどうしてもそうなる気がするんだよな。
　ポインタ通して型を潰す奴は、サイズが違うと危ないしなあ…。まー少なくとも現状でも全く効率悪くないしいいんじゃね。コピペみたいなソースが数十行あるのがうざいけど。

　そーいや前にインライン化を期待してた部分がjmpになってたけど、予測フェッチの世界だと予測コスト以外はnopと同じようなもんだったりするんだろうか？
　まあ、クリティカルなコードじゃないから、むしろメモリ消費が気になるが。一命令っつってもキャッシュライン一〜二本分だろ。ウワー重ーい。
　重くねえ。気にすんな。

　そういえばZ80を覚えようとしてた頃に見てた命令表の無条件ジャンプのとこにuncondと書いてあって、子供心にはストレートにウンコーであった。つーかその後conditional jumpという言葉を知るまでずっとウンコーであった。

　普通に考えて使えそうだったしー。馬鹿じゃーん。
　つーか、ちゃんとBoostの例文通りに書いたら通った。英文だから面倒で見てなかった。

　いや、何でこんなん使いたかったかっつーと、スレッド間で受け渡すのは結局全部PODになってて、送受信の時に無理矢理型変換とかしてる訳ですよ。えらい低レベルになったような。shared_ptr何それ的な。
　で、unsignedもsignedもfloatもdoubleもポインタもビット列変換無しに出し入れする関数が欲しくなった。
　enable_if無しで失敗した時は、まあ明示的に型指定なり関数名で型を明示するなりして我慢しようと思ったのだが、異常に大量の型明示が発生した。その上、typedefで隠蔽されたAPI引数型とかを相手にしなきゃならなくなってきて、実際の型を確認して適合する関数を毎回指定するとかやってたら色々と本末転倒かつかなり問題があるんで、どうしてもオーバーロードなりテンプレートなりで解決したくなった訳だ。boost::anyはvptrとかRTTIとか噛んでそうなので無しで。

　具体的には（実物とはだいぶ違うけど）、まずこんな感じに書いて失敗した。何度目だ。

void set ( int t ) { set_int(t); }
void set ( unsigned int t ) { set_uint(t); }
void set ( float t ); // 以下実装略
void set ( void* t );

　これでfoo.set(uint32_data);とか呼ぶと「引数tはunsigned intなんだけど、型変換すれば使える関数が三つもあるよ！　どれ使えばいいの！」とかいつものクソバカなエラー吐くんで、

template <typename T>
void set ( typename enable_if< is_signed<T>, T >::type t ) {
  set_int(t);
}
template <typename T>
void set ( typename enable_if< is_unsigned<T>, T >::type t ) {
  set_uint(t);
}
// 以下略

こんなん書いたらコンパイル通った。読み出しもインライン最適化に期待してT&を受け取る気持ち悪いテンプレート関数にした。これで型の明示も関数名書き換えも無しに読み書き可能になった。万歳。asm見たらインラインになってなかったけど。いきなりjmpするPROCとかひどいのが出来てた（笑）。まあリンクタイムの最適化もあるしな。というよりそこまでシビアじゃないっつーに。

　つーか、もっといい手は無いんだろうか。
　C的に考えると、マクロか何かで(*((uint_32t*)&t))こんなんに変換するとか。シンプルではあるなあ。オーバーロードも何も要らんですな。最適化も掛かりやすそうな。まあ今更か。不便で危険だけどシンプルで僅かに効率的かもしれない、ってことだしなあ。
　あー、64-bit対応の時はuint64_t版にifdefとかで書き換えが発生したりするのか。まー大した手間でもない気はするが。
　そういえばreinterpret_castもやったけど、static_castが出来る時はそっちでやれ、とコンパイラに怒られた。うぜえ（笑）。

　autoくれauto。何で今まで無かったんだauto。くれ。早くくれー。

　ああ、でも冷静になってみるとあれか。戻り値格納先のポインタを渡す類の関数にはもしかしてauto無理げじゃね。つーかWindowsそればっかじゃね。うぜえ（笑）。