Boost logo

Boost :

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


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

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?

Many thanks in advance for your thoughts, John.

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