chrono cleanups#1779
Conversation
mnatsuhara
left a comment
There was a problem hiding this comment.
Thanks for these cleanups! Looks good to me 😎
|
Looking through some of the PRs that merged while I was OOF, I'm wondering if we can roll any of these old comments into this PR as well:
I also suggest removing the references to "reg"/"registry" in the naming of the |
tests/std/tests/P0355R7_calendars_and_time_zones_time_zones/test.cpp
Outdated
Show resolved
Hide resolved
I was confused when I asked for that before - |
|
I've pushed additional changes:
|
mnatsuhara
left a comment
There was a problem hiding this comment.
Looks great! Thanks 🕐
<chrono>insert()-at-begin()toassign()which is strictly more efficient. This is for a freshly constructedvectorwhere onlyreserve()has been called, and this isn't in a loop, so the behavior is unchanged. (Note thatassign()preserves the reserved capacity when it's sufficient, which is the case here.)// TRANSITION: work in progressfromtzdb_list(which is complete AFAIK).get_tzdb_list()throwsruntime_errorinstead ofbad_allocfor allocation failure.get_tzdb_list()'s exception handling:_TRY_BEGINetc. to preserve our minimal support for_HAS_EXCEPTIONS=0. (We need to directly test#if _HAS_EXCEPTIONSwhen referring to_Except, because it won't be declared in_HAS_EXCEPTIONS=0mode.)runtime_errorunchanged.runtime_errorandexceptioncases, we need to__std_free_crtin order to avoid leaking.reload_tzdb()'s EH._CHRONOqualification to non-_Uglyfunction calls.tzdb_list's locking. The Standardese talks about multithreading for specific functions or pairs of functions (WG21-N4885 [time.zone.db.list]/3,front()"is thread-safe with respect toreload_tzdb()", [time.zone.db.access]/2get_tzdb_list()"It is safe to call this function from multiple threads at one time."), and the original implementation appeared to follow this strictly, but I propose to extend this by applying reader/writer locks to all member functions. (Note, for example, that if another thread is simultaneously reloading toemplace_fronta new element, neitherfront()norbegin()can be called simultaneously. The Standard says thatfront()must be thread-safe in this scenario, so we took a_Shared_lock, but it's silent aboutbegin()which really seems like a defect to me.erase_after()while someone is iterating through), but this seems like a cheap way to prevent rare catastrophes._Shared_lockhere is never manually_Unlock()ed, so we can drop that and itsbool _Ownsto be slightly more efficient.xtzdb.h,src/tzdb.cpp__std_tzdb_get_reg_leap_seconds()as_NODISCARDfor consistency and because it allocates.tests/std/include/timezone_data.hpp<string>appeared to be completely unused.P0355R7_calendars_and_time_zones_clocks/test.cpp<algorithm>forfind().const sys_days ls{ymd};, avoiding "Almost Always Auto"._Tzin test code.P0355R7_calendars_and_time_zones_io/test.cpppairCTAD instead ofmake_pair(), which is simpler (and slightly less debug codegen, not that it matters in test code).P0355R7_calendars_and_time_zones_time_zones/test.cpp