Really, there's no reason not to use BOOST_STATIC_CONSTANT (include boost/config.hpp). It replaces the integer static constant type with an enum on broken compilers and uses a more type-specific solution on standard ones. You can determine which underlying integer type to use based on how many nibbles are provided compared to the type traits of an implementation's integer types (use ::boost::uint_t and ::boost::int_t in boost/integer.hpp). Unfortunately, the user still wouldn't have direct control over what the underlying value_type is. For instance, what if they want a small value to be an unsigned long, even though an unsigned int is capable of holding such a value. Currently, you'd have to use a cast. Alternatively, you could have the user pass the prefered type to the template as well, and have instantiations use that type internally. However, if the overall goal includes being at least somewhat consistent with the functionality and useability of literals, you reach a barrier with a template version, since the formation of standard literals simply uses integer suffixes. With the macro solution you use the form BOOST_SUFFIXED_BINARY_LITERAL( 101 010101, UL ) and are able to provide any standard C++ integer suffixes. In addition, you can even use any suffixes provided as extensions for a given compiler. So not only do you get the functionality of more type-controlled literals, but you also have more consistency with standard C++ integer literals when doing so. Of course, I'm at least somewhat biased since I developed the macro version, but I'm not certain that I see any benefits of using a template here other than perhaps a religious hatred of all macros, even when used appropriately. -- -Matt Calabrese