Boost logo

Boost :

Subject: Re: [boost] [config/multiprecision/units/general] Do we have a policy for user-defined-literals?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-27 11:00:42

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at