[boost] [gsoc 13] Questions regarding Boost::chrono and as well as Boost::chrono/date

Subject: [boost] [gsoc 13] Questions regarding Boost::chrono and as well as Boost::chrono/date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-04-30 15:14:05

Hi Vicente, Howard and all, 

[First a status on my failed attempts:]

I am back with a personally disappointing news. The date<rep> turned out to
have a flawed design that I should have seen from the outset. To be
concrete, I should at least show a subset of its prototype:

template<class rep>
class date
{
    typedef date_rep_traits<rep> traits;
    rep date_mem;

public:
    typedef rep::year year;
    typedef rep::month month;
    typedef rep::day day;

    template<class rep2>
    date operator-(date<rep2>);

    template<class rep2>
    date operator<(date<rep2>);

    //and other similar operations
};

The idea being that same operations can be performed on two date objects
with different reps. But I realized this was a bad idea both in theory and
practice. I decided on this endeavor making false parallels with the rest of
the chrono library. But there, the rep is a type that behaves like an
integer. Thus, rep is pretty well defined. But in my library, rep is a full
blown class. A user of date who needs a custom rep, needs to define all its
functions like year() etc, at which point he is halfway through the whole
date class itself. What he is doing is supplying the implementation of date
class himself.

Thus, I took the wrong conclusion from the benchmark report you forwarded
[1]. Since ymd representation shines in certain cases, I sought to appease
the class that would find ymd representation better. But in applications
that require only input and output of field values year, month and day, a
simple structure would serve the purpose too:

struct simple_date
{ int year, month, date; };

And so there is no point to rep now. Moreover, since our library is general
purpose, there is no point in providing a calendar other than the dominant
one i.e. p. gregorian. The report [1] again proves that it is better in
practice too.

Thus, there is no point in making date as a template. I am sorry to say it
was needless direction but a re-reading of [1] compels me to choose the
recommendation: to implement the date class as a cached-serial
implementation.

So, I am happy to say that my proposal has actually gotten narrower than 2
days back. I will try to focus on this implementation only and make it as
fast as possible.

I need expert opinion as to whether my decision sounds sensible or not.

I have a few questions in order now after reading the discussions of the
google group you sent (lively, they were!) and other similar endeavours:

1) I saw involvement of Vicente and Howard in the current Boost.chrono
library. What inspired the library when Boost.date_time also offers a
date_time class? The motivation section in boost docs mention an open-std
paper "N2661 - A Foundation To Sleep On".

Is it true then that Boost.chrono library originated after the idea came
from the paper? If so, why is it that C++11 supports only conversion to and
from <ctime> library functions for user-readable output? Boost.chrono
duration and time_point classes provide their own output operators after
all. IMO, it reduces std::chrono to just a timestamping library, having no
features to add time of its own, but why are the actual reasons for
differences among the Boost.chrono and std::chrono library?

2) Why are we creating a date class at all, when we have a
boost::gregorian::date class already in date_time? We are duplicating
facilities all along. What the differences would be, if any, among the two?
I am totally postulating here, but is it the case that Boost.chrono/date
proposal also came through an intention to implement a C++ date class from
the ground up, without looking at related stuff in Boost that was already
done?

3) Reason for these two questions: strftime has been majorly upgraded in
C++11 and it can easily support output of date only. Why would a C++
committee approve redundancy in such functions, though agreed that a date
class is really different from a date_time class? How much support though,
should be built in a date class anyway for such functions which don't seem
to be legacy by any means?

4) I never took timezone into consideration for output. It needs to be
incorporated because it is too big an omission. I discovered it only two
hours ago so I need time to incorporate it. Are timezones other than utc and
local important? Unix, Boost.date_time and Boost.chrono seem to support
these two timezones only. What are the motivations to restrict timezones to
these two instances? They seem to be the minimum possible set required to
display time. I am still reading up on this stuff, so probably a little more
reading will answer this part.

5) Am I posting the questions in the right place, or should I take them to a
more appropriate forum?

Thanks,
Anurag Kalia.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf

--
View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-tp4646142p4646367.html
Sent from the Boost - Dev mailing list archive at Nabble.com.