Re: [boost] [chrono/date] Performance goals and design summary

Subject: Re: [boost] [chrono/date] Performance goals and design summary
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-05-04 18:05:56

>>> * *Do we need to make the separation between absolute and relative
>>>    dates?* IMO, yes. While relative dates are powerful they incur on
>>>    unwanted overhead when absolute dates are needed.
>> I can guess what you mean by relative and absolute dates, but I'd rather
>> not.  Can you briefly describe what these types of dates are?
>>
>>
> The date class of your proposal is what I call a relative date, as it 
> contains meta-data as last day of the month, 2nd sunday of month, ...
> Arithmetic on relative dates is often quite powerful. We could call them 
> contextual dates or a better name if you find it.
> What I call an absolute date is a date that has no meta-data, it defines 
> exactly a date without a context.
> 
> 28/feb/2013 is an absolute date while last/feb/2013 is a 
> relative/contextual date.
> 
> Taking one of examples in your original proposal
> 
> // Print Feb. 28 for each year in the decade
> for (date d = feb/day(28)/2010, e = feb/day(28)/2020; d != e; d +=
> years(1))
>      std::cout << d << '\n';
> 
> 
> // Print the last day in  Feb. for each year in the decade
> for (*rel_**date*  d = feb/*last*/2010,*date*  e = feb/*last*/2020; d !=
> e; d += years(1))
>      std::cout << d << '\n';
> 
> 
> rel_date implicitly converts to date of course, so that the comparison 
> works as expected, the opposite not been true.
> 
> So the following is valid
> 
>    date dt = feb/last/2020;
> 
> It is also true that this implicit conversion could result in surprising 
> behavior (as usual)
> 
> // Print Feb. 28 and notthe last day in  Feb. for each year in the decade
> for (***date*  d = feb/*last*/2010, e = feb/*last*/2020; d != e; d +=
> years(1))
>      std::cout << d << '\n';
> 
> Maybe this implicit conversion should be explicit.

I would suggest we stick to contextual dates. Relative dates are a different
concept and that can be handled competently by already existing chrono
library.

So, as per the contextual dates, this actually depends on how much staying
power we give to the word 'last'. I think the 'last' attribute ends when the
date is made.

As you rightly say, this should be made explicit. have no other suggestion
than saying that we adapt the make_date() syntax for this use-case scenario
too?

And on a tangential note, I eat my old words. In this same thread, I have
said that we should make year_month implementation defined. Now, I don't
think so. Let me give an example:

If we want to enumerate the last dates from {jul, 2013} to {jan, 2014},
current api (names may change; what matters is functionality) allows us to
write:

for(date d = date(2013, aug, 1), e = date(2014, feb, 1);
     d <= e;
     d += month(1)
    )
{
    std::cout << d - day(1) << '\n';
}

I wrote it like this because this was the cleanest I could manage. The
comparison between months of different years is clumsy. We do need a
year_month class for it. If there were one, it would look like:

for( year_month ym(2013, jul), jan14(2014, jan);
      ym <= jan14;
      ym += month(1);
    )
{
    std::cout << date(ym, last);
}

Suddenly I understand Howard's desire to include it. And I agree now. it
just makes the whole syntax easier. This leads me to my next question, are
there uses for similar class month_day?

> In your proposal, day arithmetic didn't satisfied the following
> 
>    assert((aug/last/2011 - day(1) + day(1)) == aug/last/2011);

How come it does not? The fact that the 'last' attribute gives us an
absolute date guarantees it. Am I missing something?

Regards,
Anurag.

--
View this message in context: http://boost.2283326.n4.nabble.com/chrono-date-Performance-goals-and-design-summary-tp4646619p4646672.html
Sent from the Boost - Dev mailing list archive at Nabble.com.