Re: [boost] [config/multiprecision/units/general] Do we have a policy for user-defined-literals?

Subject: Re: [boost] [config/multiprecision/units/general] Do we have a policy for user-defined-literals?
From: John Maddock (john_at_[hidden])
Date: 2013-04-28 04:12:43

>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.

I hadn't seen that before, thanks for the heads up.

If we have UDL utilities in boost then I agree they should have their own 
top-level namespace in Boost, whether it makes sense to group all literals 
in there is another matter.  My gut feeling is that users will find 
boost::mylib::literals or boost::mylib::suffixes easier, but I can see how 
it would make sense for the std to go your way.

BTW, I believe your implementation of parse_int is unnessarily complex, 
looks like that whole file can be reduced to just:

template <unsigned base, unsigned long long val, char... Digits>
struct parse_int
{
    // The default specialization is also the termination condition:
    // it gets invoked only when sizeof...Digits == 0.
    static_assert(base<=16u,"only support up to hexadecimal");
    static constexpr unsigned long long value{ val };
};

template <unsigned base, unsigned long long val, char c, char... Digits>
struct parse_int<base, val, c, Digits...>
{
    static constexpr unsigned long long char_value = (c >= '0' && c <= '9')
            ? c - '0'
            : (c >= 'a' && c <= 'f')
            ? c - 'a'
            : (c >= 'A' && c <= 'F')
            ? c - 'A'
            : 400u;
    static_assert(char_value < base, "Encountered a digit out of range");
    static constexpr unsigned long long value{ parse_int<base, val * base + 
char_value, Digits...>::value };
};

Typical usage is:

template <char...PACK>
constexpr unsigned long long operator "" _b()
{
   return parse_int<2, 0, PACK...>::value;
}

constexpr unsigned bt = 1001_b;

static_assert(bt == 9, "");

More than that though: I can't help but feel that base 8, 10 and 16 parsing 
is much better (faster) handled by the compiler, so parse_int could be 
reduced to base-2 parsing only which would simplify it still further. 
What's the rationale for the chrono integer literals parsing the ints 
themselves rather than using cooked literals?

Cheers, John.