Subject: [boost] [chrono/date] Performance goals and design summary
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 09:56:02
After the discussion on other threads I would like to summarize some of
my performances goals while refactoring the H.H chrono/date library,
just to see if I was wrong and going on the bad direction:
1. *Be able to build dates without validating them.*
2. *I wanted the library to be as efficient as possible when the user
uses constant objects or literals, no need to validate at runtime
what has already been validated by the compiler*.
3. *Possibility to reassign a date if the parameters represent a valid
4. *No a single date class is better than the others on all the
5. *No additional meta-data in absolute dates so that you don't pay for
the relative dates overhead when using absolute dates.*
6. *The user must be able to get all the date related informations at
Do you have other?
The way I have managed with these goals is
1. *P*rovide an unchecked date construction interface with a no_check_t
parameter and an is_valid() function.
2. *T*he date parts day/month/year need to be validated or constructed
3. dt.set_if_valid(year, month, day)
4. Define the Date requirements all the dates must satisfy, implement
ymd_date, days_date, ...
5. Separate the absolute and the relative Date requirements into two
Date concepts AbsoluteDate and RelativeDate. Provide at least a
relative_date class based on the ymd representation.
6. Conversion between different concrete date classe.
H.H approach respond to these goals in a different way
1. date and its parts provide constructors that are not validated, the
validation is provided by factories as operator/.
2. I don't think this can be achieved when the date must be validated.
3. No problem, this could be added to H.H approach (at least for its
4. Same approach. H.H proposes two classes chrono::day_point (only
unchecked) and YMD date.
5. I'm not sure the date YMD class doesn't include meta data (Howard
could you clarify your point here)
6. same approach.
I have some questions for followed by my personal answer;
* *Do you see some unnecessary goals, in particular, is the goal
2**necessary?* IMO, yes. Not providing an interface that allows
compiler optimizations is against the C++ philosophy. The question
is as always, what would be the gain? In the best case we could
avoid 6 comparisons.
* *Does the introduction of no_check to achieve goal 1 and 2 results
in a uglier date interface?* IMO, yes, but I don't know how to
achieve goal 2 without.
* *Should a concrete date class provide just the functionalities it is
able to do efficiently?* IMO, yes. This would prevent the user of
non efficient services (Note that my current design doesn't follows
* *Do we need a Date concept that a concrete date must model**?* IMO,
yes. SO we need two levels, level one provides the most efficient
service, level two provides an homogeneous interface.
* *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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk