HowardHinnant/date
1
0
Fork 1
mirror of https://github.com/HowardHinnant/date.git synced 2025-08-03 12:44:27 +02:00
Code Issues Packages Projects Releases Wiki Activity

Rename day_point to sys_days

Howard Hinnant
2016-05-21 11:15:34 -04:00
parent f19674358d
commit 2bf241aad1
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
FAQ.md

@@ -8,7 +8,7 @@
This library is meant to be a foundational library upon which you can efficiently build higher-level date libraries (like tz.h). A core component of this library is that it makes expensive computations explicit, so that you can see where they are in your code. Higher-level code can hide these expensive/explicit operations as desired.
A good way to estimate the cost of any given date computation is to count the number of conversions from a field type (e.g. `year_month_day` or `year_month_weekday`) to a serial type (e.g. `day_point`), and vice-versa. As an example, here is a real-world example (found in the issues list):
A good way to estimate the cost of any given date computation is to count the number of conversions from a field type (e.g. `year_month_day` or `year_month_weekday`) to a serial type (e.g. `sys_days`), and vice-versa. As an example, here is a real-world example (found in the issues list):
We need to compute the day after the 3rd Tuesday of the month. If day-oriented arithmetic was allowed on `year_month_weekday`, that would be in the form of a function like this:
@@ -16,7 +16,7 @@ We need to compute the day after the 3rd Tuesday of the month. If day-oriented
year_month_weekday
operator+(const year_month_weekday& ymwd, const days& dd) noexcept
{
return year_month_weekday{day_point{ymwd} + dd};
return year_month_weekday{sys_days{ymwd} + dd};
}
The programmer would probably use it like this:
@@ -29,10 +29,10 @@ The programmer would probably use it like this:
That is super-compact syntax! Here is what it costs:
1. Convert `tue[3]/m/y` (`year_month_weekday`) to `day_point` in order to add `days`.
2. Convert the `day_point` computed back to `year_month_weekday`.
3. Convert the temporary `year_month_weekday` computed in 2 back to `day_point`.
4. Convert the `day_point` to a `year_month_day`.
1. Convert `tue[3]/m/y` (`year_month_weekday`) to `sys_days` in order to add `days`.
2. Convert the `sys_days` computed back to `year_month_weekday`.
3. Convert the temporary `year_month_weekday` computed in 2 back to `sys_days`.
4. Convert the `sys_days` to a `year_month_day`.
4 conversions.
@@ -41,13 +41,13 @@ Here is the way you have to write this function today (because `tue[3]/m/y + day
year_month_day
get_meeting_date(year y, month m)
{
return year_month_day{day_point{tue[3]/m/y} + days{1}};
return year_month_day{sys_days{tue[3]/m/y} + days{1}};
}
The syntax is slightly more verbose in that you have to explicitly convert the `year_month_weekday` into a `day_point` in order to perform the day-oriented arithmetic. Here is what it costs:
The syntax is slightly more verbose in that you have to explicitly convert the `year_month_weekday` into a `sys_days` in order to perform the day-oriented arithmetic. Here is what it costs:
1. Convert `tue[3]/m/y` (`year_month_weekday`) to `day_point` in order to add `days`.
2. Convert the `day_point` to a `year_month_day`.
1. Convert `tue[3]/m/y` (`year_month_weekday`) to `sys_days` in order to add `days`.
2. Convert the `sys_days` to a `year_month_day`.
2 conversions. Roughly twice as fast!