C++11 user-defined literals

[Marc Glisse]

On Wed, 7 Mar 2012, Gabriel Dos Reis wrote:
> On Wed, Mar 7, 2012 at 2:27 AM, Marc Glisse <marc.glisse at inria.fr> wrote:
>> On Tue, 6 Mar 2012, Gabriel Dos Reis wrote:
>>> I believe it is actually very useful (assuming you have a C++11 
>>> compiler such as GCC-4.7.x) for reason you stated: is your integer 
>>> literal does not fit 'unsigned long' (and you would actually like to 
>>> use 'long long' or 'unsigned long long') you are kind of stuck with 
>>> the current (limited) interface.
>>
>> Do you mean that gmp should get 'long long' constructors?
>
> That will probably satisfy the C API, but my suggestion is that the
> C++ API should get the user-defined literal constructor -- you would
> not have to worry whether you need to add the 'long long long'
> constructor :-)

Well, the user-defined literal will internally use a string and thus be 
slower (that kind of construction should rarely matter for the 
performance, but who knows... and you can't even overload it so it calls a 
long long version when it fits and a string version when it doesn't). And 
people will still want interoperability with long long.

>> Unless I am missing something, whenever people write something_mpz, it will
>> be equivalent to mpz_class(something) or mpz_class("something"), which is
>> quite readable and not much longer.
>
> Yes, I find the suffix notation more readable than the string notation.

Ok, so the only benefit is readability, that was my main question, thanks. 
By the way, any opinion on the operator name? (I am not sure about _mpz)

Also, for mpq, the 2 things that seem to make sense are -123_mpq/42 and 
"-123/42"_mpq. Would you want both? If I provide a (const char*, length) 
overload, it seems to hide the (const char*) numeric overload from g++, 
and in the reverse direction, the "-123/42"_mpq version won't use the 
(const char*) overload :-(

-- 
Marc Glisse