Re: [boost] rational.hpp

From: Stephen Silver (boost_at_[hidden])
Date: 2001-01-16 19:19:38

Paul Moore wrote:

> On 15 Jan 2001, at 22:02, Jens Maurer wrote:

> > Option 1:  Use template specialization
> > 
> > Define specializations for rational<long> and rational<unsigned long>,
> > e.g. (abbreviated):
>
> Blech. Duplicate more or less the whole class just for one 
> constructor? I'd rather not do this.
>
> > Option 2: Same as option 1, but define everything except the
> > constructors in a base class:
>
> Better, but it feels untidy. Why use inheritance for a simple class 
> like this? I *assume* that there is no runtime overhead with this 
> technique? Or is there - does the derived class take up extra space 
> even though it has no data members?
>
> Regardless, it feels overcomplicated.

It's possible simply to restrict my original template constructor
so that it works only with standard integer types:

template <class T> rational(T n) : num(n), den(1)
{
    BOOST_STATIC_ASSERT((is_convertible<T,IntType>::value));
    BOOST_STATIC_ASSERT(is_standard_integral<T>::value);
}

This seems to overcome the main objection that Jens had, and it's
simpler than using template specialization.  Unfortunately, it's
still not going to work with MSVC++.

> > Completely unrelated:
> > We should probably split
> >     rational(IntType n = 0) : num(n), den(1) {}
> > into two constructors, because the default-argument version needs an
> > implicit conversion from int to IntType, which may not exist.
>
> OTOH, doesn't
>
>     rational() : num(0), den(1) {}
>
> still need an implicit conversion from int to IntType? Hmm, no. It's 
> an explicit construction. Is that better? What about my proposed
>
>     rational(IntType n = IntType(0)) : num(n), den(1) {}

I would prefer to have a separate default constructor, if for no
other reason than that it's probably more efficient (since the above
surely involves a temporary IntType object).

> Basically, I don't object to working on ensuring that rational<>
> works for a user-defined unlimited-precision integer type. But I want
> to focus on *one* such type, and not try to cover the whole range of
> possibilities. The possible trade-offs are too varied, and will leave
> no usable "lowest common denominator" for rational<> to assume.
> (The "no default conversion from int" issue is getting close to that).

I've always been happy to accept lots of requirements on the integer type.
The only one I wasn't happy with was "implicit conversion to bool".

Stephen