型変換回避コードが無駄に肥大化する


 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で型変換避けるとどうしてもそうなる気がするんだよな。
 ポインタ通して型を潰す奴は、サイズが違うと危ないしなあ…。まー少なくとも現状でも全く効率悪くないしいいんじゃね。コピペみたいなソースが数十行あるのがうざいけど。

(Visited 2 times, 1 visits today)

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください