Opened 6 years ago

Closed 5 years ago

#12299 closed Bugs (wontfix)

User-defined conversion operator from a wrapper class to a boost/multiprecision floating-point type does not compile.

Reported by: Ulrich Mutze <ulrichmutze@…> Owned by: John Maddock
Milestone: To Be Determined Component: multiprecision
Version: Boost 1.61.0 Severity: Problem
Keywords: Cc:

Description

please see the attached file.

Attachments (1)

main.cpp (3.8 KB ) - added by Ulrich Mutze <ulrichmutze@…> 6 years ago.

Download all attachments as: .zip

Change History (6)

by Ulrich Mutze <ulrichmutze@…>, 6 years ago

Attachment: main.cpp added

comment:1 by John Maddock, 6 years ago

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

comment:2 by anonymous, 6 years ago

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.

comment:3 by John Maddock, 6 years ago

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

in reply to:  3 comment:4 by anonymous, 6 years ago

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!

comment:5 by John Maddock, 5 years ago

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.