-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove macros and a compiler workaround #1307
Conversation
Moving |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't find anything to nitpick! Looks good! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pushed a minor merge conflict resolution: #1270 changed #include <errno.h>
to #include <cerrno>
in xferaise.cpp
, which we want to remove here regardless of the header name.
Changelog
xlocale
,xlocinfo.h
_XB
and_XS
. They were zero, so they served no useful purpose.xlocinfo.h
to their only usage inxlocale
, then immediately#undef
them. These macros are extremely short, making them unusually polluting.xstddef
_CLASS_DEFINE_CONST
, which was unused after constexpr INVOKE and related utilities #703.ymath.h
,src/xmath.hpp
_Feraise
argument" macros fromymath.h
(where they're visible to users viacomplex
) tosrc/xmath.hpp
(as they're used in separately compiled files only).src/xferaise.cpp
xmath.hpp
to get those macros. (This was the only file not already includingxmath.hpp
, and it drags in the previously included headers.)functional
stl vcr compiler
, so it appears that we don't need to retain this workaround for CUDA.deque
emplace_front
(which orphans) and_Emplace_back_internal
(which doesn't orphan) in a centralized manner. Note thatpush_back
already behaved like this._PUSH_FRONT_BEGIN
etc. macros (deleting unnecessary semicolons). No logic changes._DEQUEMAPSIZ
withstatic constexpr int _Minimum_map_size
,private
withindeque
._DEQUESIZ
to be astatic constexpr int
in_Deque_val
, and rename it to_Block_size
now that it's not a macro.complex
_C_COMPLEX_T
guard is necessary.filesystem
cat
,dog
,elk
elements, consistent withtests/std/tests/P0218R1_filesystem/test.cpp
. (This isn't strictly required by our policies, but it avoids potential headaches. I also believe that the animals are more readable - they're in alphabetical order and differ in their first letter, unlike the extremely similarbar
/baz
.)_File_time_clock
uses the same 100 nanosecond period assystem_clock
; simply use that type. (It's not going to change unexpectedly, due to ABI.)chrono
,xtimec.h
system_clock::period
, removing the last use of_XTIME_NSECS_PER_TICK
. Comment that this is 100 nanoseconds.ratio
denominators default to1
; taking advantage of this slightly improves clarity._XTIME_TICKS_PER_TIME_T
which was10000000LL
. That value, 10,000,000, is how many 100ns ticks occur in 1s (which is the period fortime_t
). We can and should use thechrono
/ratio
type system for this.to_time_t
takes a 100nstime_point _Time
._Time.time_since_epoch()
gives us a 100nsduration
. Previously, we extracted a raw integer with.count()
, truncate-divided by_XTIME_TICKS_PER_TIME_T
to get a raw integer of whole seconds, and then redundantly cast to__time64_t
. (That's the same as ourrep
,long long
.) Now, we can useduration_cast<seconds>
to perform the truncating conversion. Then we can extract and return.count()
. (seconds
is also represented bylong long
.)from_time_t
takes__time64_t _Tm
, a raw integer of whole seconds. We previously multiplied by_XTIME_TICKS_PER_TIME_T
to get a raw integer of 100ns ticks, then invoked theexplicit
constructors for ourduration
andtime_point
. Now, it's simpler to explicitly constructseconds{_Tm}
(again, samelong long
representation), which encodes in the type system what we know about_Tm
's meaning. Then, we can implicitly convert to ourduration
while explicitly constructing ourtime_point
. (Theduration
conversion is implicit and safe because converting from whole seconds to fine-grained 100ns ticks is information-preserving. Yaychrono
design!)ratio_multiply<ratio<100>, nano>
and we don't need to write down the inverse value_XTIME_TICKS_PER_TIME_T
.Test Coverage
This tests
to_time_t
's truncating behavior, which is the "hard" part:STL/tests/std/tests/Dev11_0555154_system_clock_to_time_t/test.cpp
Lines 17 to 32 in 5f3e912
This tests
from_time_t
's behavior:STL/tests/tr1/tests/chrono/test.cpp
Lines 203 to 206 in 5f3e912
Therefore, I believe that existing test coverage is sufficient. Just in case, I tested this manually:
Manual Testing
VS 2019 16.8 Preview 3:
This PR: