gmpxx implicit conversion between types

Marc Glisse marc.glisse at
Tue Mar 8 18:46:48 CET 2011

On Tue, 8 Mar 2011, Torbjorn Granlund wrote:

> Ok, should we allow any implicit conversions between GMP types?  I think
> C's type conversions are actively harmful, but C++ has done some cleanup
> in this area with which I am only vaguely.
> When dealing with "heavy" types like these, is it in the C++ spirit to
> allow implicit conversions?  Will we do any good by disallowing them?

I would say that the C++ spirit is to allow "safe" and natural conversions 
to happen implicitly for interoperability purposes. For instance:

void f(std::string);
f("hello"); // a std::string is safely constructed with a copy of "hello"

MyInt operator+(MyInt a,MyInt b);
a+3; // a MyInt is constructed from 3 and added to a

On the other hand, it requires an explicit conversion for unsafe or 
unexpected conversions:

creating an exception from a string (containing the error message), or a 
locale from a string (containing the name of the locale), etc

creating a smart pointer from a regular pointer

build a string from an allocator or a length

(you probably see the pattern, building an object vs converting)

A nice example in C++0X:

std::complex<float> -> std::complex<double> -> std::complex<long double>

conversions are implicit towards the right, and explicit towards the left.

Still in C++0X mode:
int i;
short s{i}; // error, narrowing conversion

>From all these examples, it looks like between mpX and mpY there should be 
an implicit conversion in a direction and an explicit one in the other 
direction. The implicit direction being consistent with the return type of 

Will we do any good?
It could help detect bugs. It lets code overloading a function for 
integers and rationals compile. It gives an automatic way to detect which 
type is "bigger".

Marc Glisse

More information about the gmp-discuss mailing list