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
BigInt_Type2 add_me(3);
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
> that.
> > I'd vote for the conservative "int only" approach.
>
> I can accept that, if someone can offer a way round the issue for
> rational<int>.
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.
Jens Maurer