My lazy, default choice is to have some fixed number of dates in the cache (they are not user-configurable). The algorithm by which they would be kept and the hashing function have not been decided.
But it wouldn't give me much. My attempt is at memoization. I want to infer data from other, already-accessed dates. For example, there can be at most 14 types of year-calendars. There are a number of properties due to recurring nature of date arithmetic. Thus, I want to, say, store 1st days of every year in the table and infer y, m, d, weekday, iso-year etc of another date in the same year from the first day of year. It would be done lazily. And the key used would be the srial itself because they are the only property we store in our date objects as well as they uniquely identify any date. You would need at least the ymd key and the days key. The first one to build your days date class and the other to get the user land year/month/day attributes.
I was talking about keys to the cache. I hope we are on the same page; ymd as key just doesn't seem right in this sense.
Have you explored the cache mechanism the Bloomberg implemented. It would be great if you can request them if you can have their implementation and the performances test they do for their paper " Towarda Standard C++’Date’Class" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf
We can do that? Though who would miss a chance to see an efficient implementation in action? I am quite interested in using the same performance test though. It would let me compare my class directly with other implementations in their paper. Is it okay to do so?
Memoization would be a bottleneck on multi-threaded systems.
Thanks! I didn't know about it.
What do you see wrong with
date d(day(7),month(12),year(2013));
respect to
date d = day(7) / month(12) / year(2013); I think the first version is wordy. There is just one additional character ;-)
Haha! true.
Some may think the second version is "too cute" (someone in the Kona-date-lib thought so), I think it is perfectly normal to try to push forward the syntax. The "<<" operator was overloaded too, and how! Dates are already used with separators. So, it is not like this library is trying to set a trend; it is merely following the age-old conventions. I think that for the standard this syntax must be proposed separately, that is it is a SHOULD feature. For Boost I think it is a MUST so that we can experiment with it.
Point. Thanks for everything! Anurag. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-... Sent from the Boost - Dev mailing list archive at Nabble.com.