From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-01-14 13:18:45
Paul Moore wrote:
> Agreed. I looked at it a few times, and I'm still not 100% sure I
> follow all of the implications. When I put it in, I got nasty ambiguity
> errors, so I need to work on it a bit more.
This is exactly my point: It's difficult to be aware of all the
implications, even as the author of the package. How much more difficult
must it be for the casual user?
> rational<BigInt> r(1,2); // Works, only one UDC
> r *= 3; // Fails, double UDC
I agree that the latter should work, but it should work (only)
because "3" is a built-in type.
There's another scenario:
rational<BigInt_Type1> r(1,2); // works
r += add_me;
Where BigInt_Type2 can be implicitly converted to BigInt_Type1.
This works with the template approach, and I'm saying that it's
reasonable far-fetched that we should not care at the moment.
> A constructor from long to rational<T> would be OK, but it would
> cause an overload clash if T was long. So I don't think we can do
> > I'd vote for the conservative "int only" approach.
> I can accept that, if someone can offer a way round the issue for
Ok, now we have a nice technical problem to solve: How to allow
for a rational(long) constructor which works even for rational<long>,
where we have to avoid ambiguities with the copy constructor.
Let me think about that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk