|
Boost : |
From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-03 12:07:12
On Tue, Sep 03, 2002 at 05:55:57PM +0200, Guillaume Melquiond wrote:
> On Tue, 3 Sep 2002, Jeff Garland wrote:
> >
> > On 2 Sep Guillaume Melquiond wrote:
> > >To use intervals for dates is something I never considered, so please
> > >excuse me if I miss the point. In my opinion, a date is just a number
> > >(maybe in a strange base). So you can use the library with it (even if I
> > >don't see the interest to use such a complex library on such a simple
> > >datatype).
> >
> > I'm not sure I see the issue here. Since a date_time type (eg: date)
> > should fail to compile since sin(date) is undefined. Since thes
> > operations are all defined as free template functions I don't see
> > a problem.
AFAICT, I think you are making the point that these free template
functions don't make a problem since they will never be instantiated.
And I agree. So as long as it does not instantiate sin(date), a program
will compile.
> Who said that sin(interval<date>) needed sin(date) to be defined for it to
> compile? It only needs the rounding policy to define two methods
> cos_down(date) and cos_up(date). And the default rounding policy doesn't
> trust the existence and precision of the transcendental functions so it
> doesn't rely on them and provides its own dummy functions. So, yes, it
> will compile.
I think that Guillaume makes an even stronger point: it will compile and
execute without throwing or dumping an assertion. It will simply return
the interval [-1,1] (dummy function). What a date does with it is its
own problem :)
And since the issue is a little moot, I suggest not wasting too much
bandwith on sin(date). I find the other problems Jeff has raised to
pertain more significantly to the issue of date intervals, and should
anyone want to pursue the issue further, these could be discussed first IMHO.
Yours,
-- Hervé
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk