|
Boost : |
From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-08 18:42:15
On Sun, 8 Sep 2002, Joerg Walter wrote:
> > Yes, the "magic"... :-)
>
> template<class U, class T>
> struct representable_traits {
> typedef char result [];
> };
>
> template<>
> struct representable_traits<float, double> {
> typedef char result [1];
> };
>
> template<class T>
> class interval_traits {
> };
>
> template<class T, class X = interval_traits<T> >
> class interval {
> public:
> interval () {}
>
> template<class U>
> interval (const interval<U, interval_traits<U> > &, typename
> representable_traits<U, T>::result = 0) {}
> };
>
> int main () {
> interval<float> fi;
> interval<double> di;
>
> interval<double> iv1 (fi);
> interval<double> iv2 (di);
> interval<float> iv3 (fi);
> // Doesn't compile.
> // interval<float> iv4 (di);
> return 0;
> }
>
> I'm sure the metaprogramming gurus could come up with a better solution ;-)
I'm really sorry to have made you write some obvious code one more time. I
knew what you were talking about; I should have been more clear than just
putting a smiley at the end of my sentence.
> > typedef typename result_type::base_type T3;
> > T3 xl = rnd.convert_down<T1>(x.lower());
> > T3 xu = rnd.convert_up <T1>(x.upper());
> > T3 yl = rnd.convert_down<T2>(y.lower());
> > T3 yu = rnd.convert_up <T2>(y.upper());
> > return result_type(rnd.add_down(xl, yl), rnd.add_up(xu, yu));
>
> I understand that something like this is necessary to get a generic solution
> including policies, but is this really neccessary for the simplified case of
> float to double promotion?
No, it isn't necessary. And an automatic promotion (and also mixed
operations) from 'interval<float>' to 'interval<double>' could have easily
been added to the library.
But our purpose was to make a general library and we didn't want to
include a mecanism that would only be used to promote 'interval<float>' to
'interval<double>'. So it isn't a technical matter, but more like an
opinion matter.
Thank you for your comments,
Guillaume
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk