Boost logo

Boost Users :

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-11-04 18:15:28


On Fri, 04 Nov 2005 09:14:38 +0100, Stering Wolfram wrote

> > I'm afraid I need a bit more context -- are you trying to
> generate a > local_time? In general I wouldn't think you would care
> about local_time for > Easter? Perhaps a bit of code to show what
> you want to do?
>
> No local_time, just a boost::gregorian::date should be generated,
> like partial_date for example.
>
> So, here we go:
> What I want to achieve is something like the following:
>
> - -----------------------------------------------
> // Use the Gauß Formula
> easter_sunday<date, GregorianEasterSundayGauss> es_gauss;
>
> // Use Oudin's Formula
> easter_sunday<date, GregorianEasterSundayOudin> es_oudin;
>
> partial_date pd( 16, Apr );
>
> date d1 = es_gauss.get_date( 2006 ); // 2006-Apr-16
> date d2 = es_oudin.get_date( 2006 ); // 2006-Apr-16
> date d3 = pd.get_date( 2006 ); // 2006-Apr-16
>
> assert( d1 == d2 );
> assert( d1 == d3 );
>
> // But, of course:
> date d4 = es_gauss.get_date( 2007 ); // 2007-Apr-08
> date d5 = pd.get_date( 2007 ); // 2007-Apr-16
>
> assert( d4 != d5 );

Thx -- that helps.

> with easter_sunday<> being defined as follows, modeled after other
> year based generators (from date_generators.hpp) with the policy
>
>...snip impl details...
>
> One remaining glitch is the typedef, as exists for the other
> generators to pull in the name into the gregorian namespace
> (gregorian_types.hpp), which is not possible for the policy-based
> easter_sunday, as a partial template specialization typedef would be
> required... It would be nice to just say
> easter_sunday<GregorianEasterSundayGauss> for example, being able to
> leave out the boost::gregorian::date.

Can't you just define the generator in boost::gregorian?
 
> A possible modification could be to change the (compile time) policy-
> based implementation to use a function pointer in the constructor to
> set the algorithm to be used (kind of Strategy pattern) at run time.

I'd rather not go there...

> Ah, yes, my original question actually was the to_string() which,
> according to the documentation of year_based_generator, is expected
> to return a string for use in a POSIX time_zone string.

Ok, I see now. You are looking the comment in the date_generator code. The
comment is basically incorrect -- you can really do whatever you want on the
to_string() function. Turns out that some of the date_generators are
essential for handling the posix_time_zone stuff -- I believe that is the
source of the comment and the original reason for the to_string(). Obviously
the 'easter' generator wouldn't be used in that context, so you can do
whatever you wish.

BTW, I'd be interested in incorporating these algorithms into the library if
you can contribute your code. To provide first class support we would need to
add i/o functions (operator<<, operator>>), write docs, tests, etc but we
could take care of some of that. Anyway, contact me offlist if you want to do
that.

Thx,

Jeff


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net