[boost] Re: Formal Review for Interval Library (was:IntervalLibraryreminder)

From: Gennadiy Rozental (gennadiy_at_[hidden])
Date: 2002-09-08 04:57:28

>   struct my_rounding {
>     ... // all the previous stuff
>     template<class Dest> Dest convert_up  (const T&);
>     template<class Dest> Dest convert_down(const T&);
>   };
>
> That's a solution. Another solution would be to have the conversion the
> other way around: 'template<class Src> T convert_...(const Src&);'. But
> these solutions suffer from the same drawback: when an user wants to add a
> new conversion to an existing policy, it's suddenly become less trivial
> (in my opinion).

How come? could not you just introduce specialization for the member
function?
In general I think that your may struggle here because of the problems in
Rounding policy design (see my review): it's to big and unite in one bottle
several implementation dependent but independent from user prospective
policies. This one would be The ConvertionPolicy. And though it may need
some staff from other rounding policies it still independent decision. Once
it become independent player it will more easy to work with it, particularly
to change it.

And here reply to Herve:
> We didn't provide it in the end because the problem remains for
> converting the policies. You may have interval<float> with your own
> rounding policy and it's not clear at all we can convert this rounding
> policy to operate on double, unless we know which policy you are using.
> We could offer the functionality for just the default policies, but that
> wouldn't be a generic solution.

As I mention in my review I do not see the reason why Rounding policies
depend on T as a template parameter. Once you exclude T problem disappear by
itself. If policies defines conversions, intervals are convertible either.

Gennadiy.