My latest proposal with changes is attached. Anurag_Kalia_chrono_date_Project_Proposal.docx http://boost.2283326.n4.nabble.com/file/n4646428/Anurag_Kalia_chrono_date_Pr... Vicente Botet wrote
Hi Vicente,
Before I start, I want to ask what I should submit as a proposal to Google? i know I am to implement date class. But the problem arises that the design and implementation are still taking time to set in. How can I tell them details that most probably would change in one way or another? What should I mention in the proposal beyond that I want to implement date class. For me it is not enough to say you want to implement a date class. H.Hinnant and myself already did that. You need to mention what are the limitation on this proposal and how you
Anurag Kalia wrote plan to solve them.
Moreover, what am I expected to do? Should I make all the implementations of major representations and then test them in the course of making the date library? I think I should (and probably I would) but I am just asking about the expectations. Again H.Hinnant and myself already do the major representations. What needs to be done is to provide the interface that satisfy most of the user expectations (don't forget that performances was one of the main issues of H.H. proposal.
Thanks! Now I know which direction to take.
You can see the project as: Given the H.Hinnant design and implementation, what needs to be changed so that the performances are improved? * date validation versus "sur parolle" valid dates, * relative dates should not reduce the performances of absolute dates, * some algorithms are more efficient with one or another representation.
Okay. As I have already mentioned, an application requiring absolute performance from date class would use its operations. And nothing can beat a serial representation at comparisons, assignments and day/week arithmetic. ymd represntations, OTOH, optimize I/O. And an application requiring such optimization can simply employ a representation like: struct date { int y, m, d; }; which serves their purpose well enough. For the vast majority however, serial representation is good enough. After caching as you know, performance nears ymd in these scenarios too.
I can see use of all constructors except the day_of_year constructor. Why? This is an alternative representation. Since we are making it a p. gregorian calendar, such interface shouldn't be made public. It should rather be used in dayofyear_claendar where concept of months doesn't exist, shouldn't it? I disagree here. 125th day of 2013 is a valid date.
I agree and don't deny that such notation doesn't have use in the world. But, I am proposing that the ordinal date should be used in its own calendar. If it makes our programming easy, it should become a private constructor instead. Haven't we designed our date class to belong to a specific calendar only? I am not favouring this constructor only and only by design.
I genuinely am curious why adding that fourth parameter might be a bad design. Well, this is a taste question. I will comeback to your functional format later.
I myself have dropped this constructor. After all, it is not difficult for users to check documentation for the order of the date parameters. It just eats up the performance anyway, even if it is just a switch statement.
I was talking about stream Input/output
I didn't know much about localization before today. I get the basic understanding of basics of locale and facets now. I have to study more about them.
What I mean is that a date can not inherit from a days point, this is horrible.
In the new representation, I have tried less to keep synergies between
current chrono library and date class. I have provided explicit functions
instead to convert to/from time_point