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