Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at