--編集-質問を解決しました:最後のサイドノートへのコメントが役に立ちます。また、phoenix :: bindオーバーロード処理に関するコメントも役立ちます(私の答えでは)。
私は厳密な型指定要件のあるシステムで作業しています。int32_tとint64_tの制約を満たす整数を解析していることを確認したいのですが、解析された文字列を合成して上記の型に制約するパーサーは必要ありません。
これについてはどうすればよいですか?ドキュメントにはlong_long
、64ビットをサポートするプラットフォームでのみ使用可能であると記載されていますが、32ビットプラットフォームでもint64_tを解析する必要があります。
私のパーサーからの抜粋は次のとおりです。
...
eps(_b == VALUE_INT4) >> qi::long_
[phoenix::bind(&AddEntry, _r1,_a, _1, _pass)] ) //
| ( eps(_b == VALUE_INT8) >> qi::long_long)
...
AddEntryにはint32_t
オーバーロードとint64_t
オーバーロードがありますが、phoenix :: static_cast_は順番にオン_1
になっていますか?この場合、最新の32ビットプラットフォームで64ビット整数を解析するにはどうすればよいですか?8008BOOST_HAS_LONG_LONG
のような古風なハードウェアでは定義されていないだけだと思います;)。
<Rant>
彼らがc99で設定された標準に固執していればよかった<boost/cstdint.hpp>
のですが、私たちのほとんどはクリーンな抽象化に対してプログラミングしたいと思っています。数値パーサーがそのように定義されているのには、おそらく正当な理由があります。ただし、グランドスキームの使用は、ドキュメントでより適切に定義できます。
</Rant>
補足:上記の条件付きイプシロンスタイルは、パフォーマンスのケースステートメントに匹敵しますか?