Le 27/04/13 14:29, John Maddock a écrit :
Folks,
I've been experimenting with the new C++11 feature "user-defined-literals", and they're pretty impressive ;-)
So far I've been able to write code such as:
auto i = 0x1234567890abcdef1234567890abcdef_cppi;
and generate value i as a signed 128-bit integer. It's particulary remarkable because:
* It actually works ;-) * The value is generated as a constexpr - all evaluation and initialization of the multiprecision integer is done at compile time. * The actual meta-code is remarkably short and concise once you've figured out how on earth to get started!
Note however my code is limited to hexadecimal constants, because it can't do compile time radix conversion - that would require a huge meta-program for each constant :-(
This is obviously useful to the multiprecision library, and I'm sure for Units as well, but that leaves a couple of questions:
1) We have no config macro for this new feature (I've only tested with GCC, and suspect Clang is the only other compiler with support at present). What should it be called? Would everyone be happy with BOOST_NO_CXX11_USER_DEFINED_LITERALS ? This is fine. clang uses __has_feature(cxx_user_literals) 2) How should libraries handle these user defined suffixes? The essencial problem is that they have to be in current scope at point of use, you can never explicitly qualify them. So I suggest we use:
namespace boost{ namespace mylib{ namespace literals{
mytype operator "" _mysuffix(args...);
}}}
Then users can import the whole namespace easily into current scope right at point of use:
int main() { using namespace boost::mylib::literals; boost::mylib::mytype t = 1234_mysuffix; }
If http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3402.pdf is the final version accepted for C++14, the standard will use, e.g. namespace std { namespace suffixes { namespace chrono { One of the advantages is that we can add some utilities. I helped Peter Sommerlad to port his reference implementation to Boost (See https://github.com/PeterSommerlad/UDLSuffixBoost/tree/master/boost/suffixes). There are some interesting utilities that make easier implementing suffixes. I guess it would like to name his library Boost.Suffixes. This doesn't means that we can not choose your option.
3) How should the suffixes be named? There is an obvious possibility for clashes here - for example the units lib would probably want to use _s for seconds, but no doubt other users might use it for strings and such like. We could insist that all such names added to a boost lib are suitably mangled, so "_bu_s" for boost.units.seconds, but I'm not convinced by that. Seems to make the feature much less useful?
I agree with Steven. We should choose the better suffixes for the specific domain independently of other suffixes on other libraries. Best, Vicente