Boost C++ Libraries: Ticket #12299: User-defined conversion operator from a wrapper class to a boost/multiprecision floating-point type does not compile.

attachment set

Thu, 23 Jun 2016 15:30:14 GMT

attachment → main.cpp

John Maddock — Fri, 24 Jun 2016 17:41:50 GMT

I'm having a hard time figuring out why this would work for type double actually - though it clearly does so.... do you have a reference to which part of the standard requires the conversion operators to be invoked in this case?

BTW if you typedef R to complex<double> it fails for the same reason as Boost does.

A quick and dirty workaround would be to add arithmetic operators for type R1:

inline R operator+(const R1& a, const R1& b) { return (R)a + (R)b; }

I could also add more overloaded operators for type number to handle this specific case, but I'm not entirely sure what the consequences would be (other than even longer compile times).

Thanks for reporting this, it's an interesting and somewhat perplexing corner case...!

anonymous — Fri, 24 Jun 2016 19:58:57 GMT

I'm having a hard time too understanding why my compiler does not respect what Stroustrup's 'The C++ programming language', 4th edition, says on the first half of p. 544. For exemplification he defines a class Tiny of small integers and endows it with the arithmetic facilities of type int by providing a member function Tiny::operator int()const which is asserted to effect implicit conversion (if a direct function call is not defined). Not being really familiar with the standard I simply googled 'conversion operator C++ standard' and got a page that seemed to me expressing the same in a more formal language. On the other hand, all my attempts to define 'R' as a simple self-made class, for which the intended type conversion would work, failed. So, the problem seems to be one of modern C++ implementations more than one of boost/multiprecision. However, it should be noted that (at least on my system) R1 works as intended for R defined as mpreal.

John Maddock — Sat, 25 Jun 2016 12:25:48 GMT

However, it should be noted that (at least on my system) R1 works as intended for R defined as mpreal.

Not for me with mpreal 3.6.2: I get the same error as I see with Boost.Multiprecision... ah wait this is with VC++, with GCC it compiles OK. I suspect GCC accepts the code only because mpreal and it's overloaded operators are non-templates. Not sure about that, as I still don't really understand why this would work in the first place.... in any case having thought about this some more I don't actually see any way to fix this inside Multiprecision :(

anonymous — Tue, 28 Jun 2016 10:00:45 GMT

Replying to johnmaddock:

However, it should be noted that (at least on my system) R1 works as intended for R defined as mpreal.

Not for me with mpreal 3.6.2: I get the same error as I see with Boost.Multiprecision... ah wait this is with VC++, with GCC it compiles OK. I suspect GCC accepts the code only because mpreal and it's overloaded operators are non-templates. Not sure about that, as I still don't really understand why this would work in the first place.... in any case having thought about this some more I don't actually see any way to fix this inside Multiprecision :(

I agree. If it is a problem (I'm convinced that it is one) it is one for GCC. So I sent a bugreport to them where it got a Ticket 71658. When the matter is clarified there, I probably will come back to boost/multiprecision. Meanwhile I don't expect action from your side. Thanks a lot so far!

status changed; resolution set

John Maddock — Sat, 30 Dec 2017 19:04:41 GMT

status new → closed
resolution → wontfix